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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the stage 2 description (architectural solution and functionalities) for the MBMS Bearer 
Service, which includes, together with MBMS User Services defined in TS 26.346 [7], all the elements necessary to 
realise the stage 1 requirements in TS 22.146 [2] and TS 22.246 [6]. 

The present document also includes considerations on the manner in which User Services should make use of the 
MBMS Bearer Service described herein. It should be noted that the specification of MBMS User Services in 
TS 26.346 [7] takes precedence over User Service aspects described in this document. 

The present document includes information applicable to network operators, service providers and manufacturers. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 



• 



References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 22.146: "Multimedia Broadcast/Multicast Service; Stage 1". 

[3] 3GPP TS 23.107: "Quality of Service (QoS) concept and architecture". 

[4] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting 

packet based services and Packet Data Networks (PDN)". 

[5] 3GPP TS 33.246: "Security of Multimedia Broadcast/Multicast Service". 

[6] 3GPP TS 22.246: "Multimedia Broadcast/Multicast Service (MBMS) user services". 

[7] 3GPP TS 26.346: "MBMS: Protocols and Codecs". 

[8] void. 

[9] void. 

[10] 3GPP TS 25.346: "Introduction of the Multimedia Broadcast Multicast Service (MBMS) in the 

Radio Access Network". 

[II] 3GPP TS 43.246: "Technical Specification Group GSM/EDGE Radio Access Network; 
Multimedia Broadcast Multicast Service (MBMS) in the GERAN". 

[12] 3GPP TS 23.125: "Overall high level functionality and architecture impacts of flow based 

charging; Stage 2". 

[13] 3GPP TS 23.003: "Numbering, addressing and identification". 

[14] 3GPP TS 32.422: "Subscriber and equipment trace; Trace control and Configuration Management 

(CM)". 

[15] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[16] 3GPP TS 25.446: "MBMS synchronisation protocol (SYNC)". 
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[17] IETF RFC 3376: "Internet Group Management Protocol, Version 3". 

[18] IETF RFC 3810: "Multicast Listener Discovery Version 2 (MLDv2) for IPv6". 

[19] IETF RFC 4607: "Source-Specific Multicast for IP". 

[20] IETF RFC 4604: "Using Internet Group Management Protocol Version 3 (lGMPv3) and Multicast 

Listener Discovery Protocol Version 2 (MLDv2) for Source specific Multicast". 

[21] IETF RFC 4601: "Protocol Independent Multicast - Sparse Mode (PIM-SM)". 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions defined in TR 21.905 [1] and TS 22.146 [2] and the 
following apply: 

MBMS Service Announcement: Mechanism to allow users to be informed about the MBMS user services available. 

MBMS Bearer Service: the service provided by the PS Domain to MBMS User Services to deliver IP multicast 
datagrams to multiple receivers using minimum network and radio resources. 

MBMS User Service: the MBMS service provided to the end user by means of the MBMS Bearer Service and possibly 
other capabilities. 

MBMS Service Area: The area within which data of a specific MBMS session are sent. Each individual MBMS 
session of an MBMS Bearer Service may be sent to a different MBMS Service Area. This MBMS Service Area is the 
same or a subset of the Multicast or Broadcast Service Area as defined in TS 22.146 [2]. An MBMS Service Area 
smaller than the Multicast or Broadcast Service Area is typically used for localized services. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations in TR 21.905 [1] and TS 22.146 [2] apply. 

SSM Source Specific Multicast 

TMGI Temporary Mobile Group Identity 

TPF Traffic Plane Function 



IVIBIVIS Architecture 



4.1 Overview 

MBMS is a point- to -multipoint service in which data is transmitted from a single source entity to multiple recipients. 
Transmitting the same data to multiple recipients allows network resources to be shared. 

The MBMS bearer service offers two modes: 

Broadcast Mode; 

- Multicast Mode. 

MBMS architecture enables the efficient usage of radio-network and core-network resources, with an emphasis on radio 
interface efficiency. 

MBMS is realised by the addition of a number of new capabilities to existing functional entities of the 3GPP 
architecture and by addition of a number of new functional entities. 
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The existing PS Domain functional entities (GGSN, SGSN, UTRAN, GERAN and UE) are enhanced to provide the 
MBMS Bearer Service. In the bearer plane, this service provides delivery of IP Multicast datagrams from the Gi 
reference point to UEs with a specified Quality of Service. In the control plane, this service provides mechanisms for: 

managing the MBMS bearer service activation status of UEs (in the case of multicast mode); 

outsourcing authorisation decisions to the MBMS User Service (i.e. to the BM-SC) (in the case of multicast 
mode); 

providing control of session initiation/termination by the MBMS User Service and managing bearer resources 
for the distribution of MBMS data (in the case or multicast and broadcast modes). 

A particular instance of the MBMS Bearer Service is identified by an IP Multicast Address and an APN Network 
Identifier. 

The boundary of the MBMS Bearer Service is the Gmb and Gi reference points as shown in Figure 1 below. The former 
provides access to the control plane functions and the latter the bearer plane. 

A functional entity, the Broadcast Multicast Service Centre (BM-SC) provides a set of functions for MBMS User 
Services. BM-SC functions for different MBMS User Services may be supported from the same or different physical 
network elements. 



4.2 



Reference Architecture Model 



PDN 

(e.g . Internet ) 



UE 



UE 

Note 1 : 

Note 2: 
Note 3: 




GGSN 
TPF 




GERAN 



network entities and reference points solely used by the MBMS user service (e.g. for service 

announcement as described in section 4.4.1 .2) are not shown in this figure. 

Gp applies only when SGSN and GGSN are in different PLMNs. 

the lu/Gn reference point above is a direct tunnel according to clause 5.6.2.2, figure 6b in TS 23.060 [15] 

with IP multicast based addressing according to RFC 4607 [19]. 

Figure 1 : Reference architecture to support the lUIBIUIS bearer service 



4.3 MBMS Specific Reference points 
4.3.1 Gmb 

Signalling between GGSN and BM-SC is exchanged at Gmb reference point. This represents the network side boundary 
of the MBMS Bearer Service from a control plane perspective. This includes user specific Gmb signalling and MBMS 
bearer service specific signalling. 

MBMS bearer service specific Gmb signalling: 

- The GGSN establishes the MBMS bearer context and registers at BM-SC. 
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- The GGSN or the BM-SC releases the MBMS bearer context and de-registers the GGSN from the BM-SC. 

The BM-SC indicates session start and stop to the GGSN including session attributes like QoS and MBMS 
service area. 

User specific Gmb signalling: 

The BM-SC authorises the user specific MBMS multicast service activation (join) at the GGSN. 

The GGSN reports to the BM-SC the successful user specific MBMS multicast activation (join) to allow the 
BM-SC to synchronise the BM-SC MBMS UE context with the MBMS UE contexts in the SGSN and GGSN. 

The GGSN reports to the BM-SC when a user specific MBMS multicast service is released or deactivated (e.g. 
at implicit detach). The GGSN makes this report in order to synchronise the BM-SC MBMS UE context with the 
MBMS UE contexts in the SGSN and GGSN. 

The BM-SC initiates the deactivation of a user specific MBMS bearer service when the MBMS user service is 
terminated. 

BM-SC functions for different MBMS bearer services may be provided by different physical network elements. Further, 
MBMS bearer service specific and user specific signalling for the same MBMS bearer service may also be provided by 
different physical network elements. To allow this distribution of BM-SC functions, the Gmb protocol must support the 
use of proxies to correctly route the different signalling interactions in a manner which is transparent to the GGSN. 

4.3.2 Mz 

Mz is the roaming variant of the Gmb reference point with the same functionality as described under Gmb, i.e. with 
MBMS bearer and User specific signalling. 

MBMS bearer and User specific Mz signalling is used between a BM-SC in the visited PLMN and a BM-SC in the 
home PLMN when MBMS services from the home PLMN are offered by the visited PLMN. 

User specific signalling is used between a BM-SC in the visited PLMN and a BM-SC in the home PLMN when the 
visited PLMN offers MBMS user services to roaming users. This user specific Mz signalling provides home PLMN 
authorisation for MBMS user services that are provided by the visited PLMN. This mechanism supports only MBMS 
user service classes that are offered by the visited and by the home PLMN. 

Mz may use proxying capabilities as described for Gmb, e.g. to proxy signalling between BM-SCs. An APN may be 
included in the signalling between BM-SCs, which is used to select an appropriate GGSN to access the MBMS service 
aiming for an optimized routing, resource saving, or operator policy. 

4.3.3 Void 



4.4 MBMS Service Provision 
4.4.1 IVIULTICAST IVIODE 

Reception of an MBMS MULTICAST service is enabled by certain procedures that are illustrated in the Figure below. 
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Subscription 



Service announcement 



Joining 



Session start 



IVIBIVIS notification 



Data transfer 



Session Stop 



Leaving 




Figure 2: Phases of MBMS Multicast service provision 

The phases subscription, joining and leaving are performed individually per user. The other phases are performed for a 
service, i.e. for all users interested in the related service. The sequence of phases may repeat, e.g. depending on the need 
to transfer data. Also subscription, joining, leaving, service announcement as well as MBMS notification may run in 
parallel to other phases. 

This is illustrated with the following example of timeline: 
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Figure 3: Timeline example 



4.4.1.1 



Subscription 



Establishes the relationship between the user and the service provider, which allows the user to receive the related 
MBMS multicast service. 

Service Subscription is the agreement of a user to receive service(s) offered by the operator. Subscription information is 
recorded in the BM-SC. Subscription information and other BM-SC functionality may be on separate entities, which is 
enabled by proxy capability of the Gmb interface. 

NOTE: procedures for the subscription phase are out of scope of this specification. 



4.4.1.2 



Service announcement 



MBMS user service announcement/discovery mechanisms shall allow users to request or be informed about the range 
of MBMS user services available. This includes operator specific MBMS user services as well as services from content 
providers outside of the PLMN. Service announcement is used to distribute to users information about the service, 
parameters required for service activation (e.g. IP multicast address(es)) and possibly other service related parameters 
(e.g. service start time). 

Operators/service providers may consider several service discovery mechanisms. This could include standard 
mechanisms such as SMS, or depending on the capability of the terminal, applications that encourage user interrogation. 
The method chosen to inform users about MBMS user services may have to account for the user' s location, (e.g. current 
cell, in the HPLMN or VPLMN). Users who have not already subscribed to a MBMS user service should also be able to 
discover MBMS user services. 

The following could be considered useful for MBMS user service announcement mechanisms (not exhaustive): 

SMS Cell Broadcast to advertise MBMS Multicast and Broadcast user services; 

- MBMS Broadcast mode to advertise MBMS Multicast and Broadcast user Services; 
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- MBMS Multicast mode to advertise MBMS Multicast user Services; 

- PUSH mechanism (WAP, SMS-PP, MMS); 

- URL (HTTP, FTP). 

The details of the MBMS service announcement mechanisms are out of scope of this specification, but MBMS shall 
allow the utilisation of solutions using IETF protocols. 

Service announcement is further defined within MBMS User Service specifications TS 26.346 [7]. 

4.4.1.3 Joining 

Joining (i.e. MBMS multicast activation by the user) is the process by which a subscriber joins (becomes a member of) 
a multicast group, i.e. the user indicates to the network that he/she wants to receive Multicast mode data of a specific 
MBMS bearer service. An MBMS user service may also be carried by more than one MBMS bearer service. In that 
case the MBMS user service part in the UE initiates the relevant MBMS bearer services to receive the service (see 
subclause 8.2). 

4.4.1.4 Session Start 

Session Start is the point at which the BM-SC is ready to send data. This can be identified with the start of a "Multicast 
session" as defined in TS 22. 146 [2]. Session Start occurs independently of activation of the service by the user - i.e. a 
given user may activate the service before or after Session Start. Session Start is the trigger for bearer resource 
establishment for MBMS data transfer. If an MBMS user service is carried by more than one MBMS bearer service, a 
Session Start message is sent for each MBMS bearer service. In that case the UE may need to initiate the reception of 
multiple relevant MBMS bearer services to receive the MBMS user service. 

4.4.1.5 MBMS notification 

Informs the UEs about forthcoming (and potentially about ongoing) MBMS multicast data transfer. 

4.4.1.6 Data transfer 

It is the phase when MBMS data are transferred to the UEs. 

4.4.1.7 Session Stop 

It is the point at which the BM-SC determines that there will be no more data to send for some period of time - this 
period being long enough to justify removal of bearer resources associated with the session. At Session Stop, the bearer 
resources are released. 

4.4.1.8 Leaving 

Leaving (i.e. MBMS multicast deactivation by the user) is the process by which a subscriber leaves (stops being a 
member of) a multicast group, i.e. the user no longer wants to receive Multicast mode data of a specific MBMS bearer 
service. 

4.4.2 Multicast Mode timeline 

4.4.2.1 Period between Service Announcement and Session Start 

The service announcement may contain a schedule of Session Start times and may be sent some time before the service 
is due to start. So, this time period could be hours, days or even weeks. 

4.4.2.2 Period between Service Announcement and Service Subscription 

Service Subscription can be done anytime before or after Service announcement. 
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4.4.2.3 Period between Service Announcement and Joining 

The Joining time is chosen by the user and/or UE possibly in response to a Service Announcement. Users will typically 
join at the time of their choosing so that the period between announcement and joining may be very long or very short. 
In order to avoid overload situations being caused by many users attempting to join in a short period of time, the UE 
shall be able to use parameters sent by the BM-SC in the service announcement to randomise the joining time. 

4.4.2.4 Period between Joining and Session Start 

Some MBMS bearer services may be 'always on'. In this case, Joining can take place immediately after Service 
Announcement and possibly many hours before, or after. Session Start. 

In other cases, if a Session Start time is known. Joining may take place immediately before Session Start or after 
Session Start. For these services, the announcement may contain some indication of a time period which users and UEs 
should use to choose a time to Join the MBMS bearer service. 

4.4.2.5 Period between Session Start and First Data Arrival 

Session Start indicates that the transmission is about to start. The time delay between a Session Start indication and 
actual data should be long enough for the network actions required at Session Start to take place e.g. provision of 
service information to the UTRAN, establishment of the bearer plane. 

Session Start may be triggered by an explicit notification from the BM-SC. In the case of bearer plane resources which 
are set-up after the start of session data transmission, the network is not required to buffer the session data and loss of 
data can be assumed. 

4.4.2.6 Period between Session Start and Session Stop 

When the BM-SC knows that there is no more data to be sent for a "long idle period", it should indicate Session Stop to 
the network, causing the release of bearer resources. However, if this idle period with no data is short, this may not be 
appropriate as it brings more signalling and processing. 

The duration of this "long idle period" is implementation dependent. The order of magnitude should be defined to take 
into account network constraints (including UTRAN, GERAN, and CN). 

If the BM-SC wants to use session repetition identification on the MBMS bearer service level, the BM-SC must stop the 
MBMS session before starting the next MBMS user service session for that TMGI. 

4.4.2.7 Session Update 

Session Update is used to update specific parameters of an ongoing MBMS Multicast session. The SGSN can use the 
procedure to update the list of RAs where MBMS multicast users are located for an ongoing MBMS Multicast service 
session. 

4.4.3 BROADCAST MODE 

An example for the phases of MBMS broadcast service provision is described in the figure below: 
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Service announcement 



Session Start 



IVIBIVIS notification 



Data transfer 



Session Stop 




Figure 4: Phases of MBMS broadcast service provision 

The sequence of phases may repeat, e.g. depending on the need to transfer data. It is also possible that the service 
announcement and MBMS notification phase may run in parallel with other phases, in order to inform UEs which have 
not yet received the related service. 
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Broadcast of Data, received by any UE 
which is present 



Figure 5: Broadcast service timeline 

4.4.3.1 Service announcement 

Informs UEs about forthcoming MBMS user services. Also see section on Multicast mode (4.4.1.2). 



4.4.3.1a 



UE local service activation 



The MBMS user service part in the UE initiates reception of the MBMS bearer service to receive an MBMS user 
service. In case one MBMS user service is carried by more than one MBMS bearer service, the UE may need to initiate 
the reception of multiple relevant MBMS bearer services to receive the MBMS user service (see subclause 8.12). 



4.4.3.2 



Session Start 



Session Start is the point at which the BM-SC is ready to send data. This can be identified with the start of a "Broadcast 
session" as defined in TS 22. 146 [2]. Session Start is the trigger for bearer resource establishment for MBMS data 
transfer. If an MBMS user service is carried by more than one MBMS bearer service, a Session Start message is sent for 
each MBMS bearer service. In that case the UE may need to initiate the reception of multiple relevant MBMS bearer 
services to receive the MBMS user service. 

4.4.3.3 MBMS notification 

Informs the UEs about forthcoming (and potentially about ongoing) MBMS broadcast data transfer. 

4.4.3.4 Data transfer 

It is the phase when MBMS data are transferred to the UEs. 
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4.4.3.5 Session Stop 

It is the point at which the MBMS user service determines that there will be no more data to send for some period of 
time - this period being long enough to justify removal of bearer resources associated with the service. At Session Stop, 
the bearer resources are released. 

4.4.3.6 Session Update 

Session Update is used to update specific parameters of an ongoing MBMS Broadcast session. Parameters which can be 
updated are MBMS Service Area, and/or the List of SGSNs (only from BM-SC to GGSN). A Session Update received 
in one node, results in a Session Update being sent to downstream nodes, to inform of the changed MBMS Service 
Area. When a Session Update is received in the GGSN including the List of SGSN parameter, it results in a Session 
Start being sent to new downstream nodes, and in a Session Stop being sent to downstream nodes that have been 
removed from the list. 

4.4.4 Broadcast Mode timeline 

4.4.4.1 Period between Service Announcement and Session Start 

Same as for Multicast mode. 

4.4.4.2 Period between Session Start and First Data Arrival 

Same as for Multicast mode. 

4.4.4.3 Period between Session Start and Session Stop 

Same as for Multicast mode. 



Functional Entities To Support IVIBIVIS 



5.0 General 

To provide MBMS bearer services existing functional entities, GGSN, SGSN, RNC/BSC, perform several MBMS 
related functions and procedures, some of which are specific to MBMS. An MBMS specific functional entity - 
Broadcast Multicast Service Centre (BM-SC) supports various MBMS user service specific services such as 
provisioning and delivery. 

5.1 Broadcast-Multicast Service Centre (BM-SC) 

The BM-SC provides functions for MBMS user service provisioning and delivery. It may serve as an entry point for 
content provider MBMS transmissions, used to authorise and initiate MBMS Bearer Services within the PLMN and can 
be used to schedule and deliver MBMS transmissions. 

The BM-SC is a functional entity, which must exist for each MBMS User Service. 

The BM-SC consists of the following sub -functions: 

Membership function; 

Session and Transmission function, including content synchronization and header compression; 

Proxy and Transport function; 

Service Announcement function; 

Security function. 
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This section describes BM-SC functions, which are defined for the standardised MBMS User Services. 
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Figure 5a: BM-SC functional structure 



5.1.1 Membership Function 



The BM-SC Membership function provides authorization for UEs requesting to activate an MBMS service. 

The Membership function may have subscription data of MBMS service users. 

The Membership Function may generate charging records for MBMS service users. 

The Membership Function is an MBMS bearer service level function, but it may also provide user service level 
functions e.g. membership management etc. In this case it does also have a Gi interface. 

5.1 .2 Session and Transmission Function 

The BM-SC Session and Transmission Function shall be able to schedule MBMS session transmissions. 

The BM-SC Session and Transmission Function should be able to schedule MBMS session retransmissions, and label 
each MBMS session with an MBMS Session Identifier to allow the UE to distinguish the MBMS session 
retransmissions. The BM-SC Session and Transmission Function allocates TMGIs. 

Each transmission and subsequent retransmission(s) of a specific MBMS session are identifiable by a common MBMS 
Session Identifier (2-3 Octets) passed at the application layer in the content, and also passed in a shortened form (i.e. the 
least significant octet) in the MBMS Session Start Request message to the RNCs/BSCs. The full MBMS Session 
Identifier should be used by the UE to identify an MBMS session when completing point-to-point repair, while the 
shortened MBMS Session Identifier is included by the RANs in the notification messages for MBMS 

The BM-SC Session and Transmission Function shall be able to provide the GGSN with transport associated 
parameters such as quality-of-service and MBMS service area. 

The BM-SC Session and Transmission Function shall be able to initiate and terminate MBMS bearer resources prior to 
and following transmission of MBMS data. 

The BM-SC Session and Transmission Function should be able to send MBMS data. It could also apply favourable 
error resilient schemes e.g. specialized MBMS codecs or Forward Error Correction schemes. 

When IP multicast is used for distribution of payload from GGSN to RNC, the BM-SC Session and Transmission 
Function shall include synchronization information for the MBMS payload. If the header compression is used over 
radio the compression is done in the BM-SC. The details of synchronization and header compression for the MBMS 
payload are specified in TS 25.346 [10] and TS 25.446 [16]. 

The BM-SC Session and Transmission Function should be able to authenticate and authorize external sources and 
accept content from them. 
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The Session and Transmission Function is user service level function and it triggers bearer level functions when MBMS 
sessions are scheduled. 

5.1 .3 Proxy and Transport Function 

The BM-SC Proxy and Transport Function is a Proxy Agent for signalling over Gmb reference point between GGSNs 
and other BM-SC sub-functions, e.g. the BM-SC Membership Function and the BM-SC Session and Transmission 
Function. Further, the BM-SC Proxy and Transport Function shall also be able to handle when BM-SC functions for 
different MBMS services are provided by multiple physical network elements. Routing of the different signalling 
interactions shall be transparent to the GGSN. 

The BM-SC Proxy and Transport function shall be able to generate charging records for content provider charging of 
transmitted data. Content provider name is provided to BM-SC Proxy and Transport function over Gmb at session start. 

The BM-SC Proxy and Transport function may act as an intermediate device for the MBMS data sent from the BM-SC 
Session and Transmission function to the GGSN. 

The Proxy and Transport Function may be divided further into a Proxy function managing the control plane (Gmb) and 
a Transport function managing the multicast payload. 

The Proxy and Transport Function is an MBMS bearer service function. 

5.1 .4 Service Announcement Function 

The BM-SC Service Announcement function shall be able to provide service announcements for multicast and 
broadcast MBMS user services. 

The BM-SC Service Announcement function shall be able to provide the UE with media descriptions specifying the 
media to be delivered as part of an MBMS user service (e.g. type of video and audio encodings). 

The BM-SC Service Announcement function shall be able to provide the UE with MBMS session descriptions 
specifying the MBMS sessions to be delivered as part of an MBMS user service (e.g. multicast service identification, 
addressing, time of transmission, etc.). 

The BM-SC Service Announcement function shall be able to deliver media and session descriptions by means of 
service announcements using IETF specified protocols over MBMS multicast and broadcast bearer services. 

The Service Announcement Function is a user service level function. 

The following mechanisms should be supported for service announcement. Service announcements may be triggered by 
the BM-SC but are not necessarily sent by the BM-SC: 

MBMS bearer capabilities to advertise MBMS user Services; 

- PUSH mechanism (WAP push); 

- URL (WAP, HTTP); 

- SMS (point-to-point); 

- SMS-CB cell broadcast. 

Other mechanisms could be considered in future releases. 



5.1 .4a MBMS Security Function 



MBMS user services may use the Security functions for integrity and/or confidentiality protection of MBMS data. 
The MBMS Security function is used for distributing MBMS keys (Key Distribution Function) to authorized 
UEs. Detailed description of the security functions is provided in (TS 33.246 [5]). 
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5.1 .5 MBMS Content Transfer for 2G and 3G for the same MBMS User 
Service 

5.1.5.1 General 

Although these procedures mention 2G and 3G extensively, only the BM-SC (which renders the content differently) and 
the SGSN have to implement functionality to deliver this. The GGSN, RNC and BSC shall all be transparent to this 
functionality. 

5.1 .5.2 Separate MBMS Bearer Services for 2G and 3G for the same MBMS User 
Service 

The same MBMS user service may transfer its data on separate MBMS bearer services for 2G or 3G coverage, typically 
with different QoS. For this purpose two IP multicast addresses and the associated two TMGIs should be allocated for 
the same MBMS user service. One pair of IP multicast address and TMGI is for 2G coverage and another pair of IP 
multicast address and TMGI is for 3G coverage. The detailed impacts on the network nodes are listed below: 

a) The service announcement instructs the UE to join two multicast MBMS bearer services (one is for 2G coverage 
and the other is for 3G coverage), i.e. two IP multicast addresses that are allocated in the BM-SC are sent to UE 
within one service announcement message. 

NOTE 1: One MBMS User Service may use several MBMS Bearer Services. 

b) A UE that might move between 3G coverage areas and 2G coverage areas activates both MBMS bearer services. 

c) The UE monitors the paging/notification channels for both TMGIs and receives MBMS data when transferred by 
the MBMS bearer services. 

d) When the BM-SC needs to deliver the content, the BM-SC produces two sets of MBMS data from the same 
content and sends independent Session Start messages for both of the MBMS bearer services. The "different" 2G 
and 3G content streams for the same MBMS user service are sent on the different IP multicast address associated 
with 2G and 3G TMGIs. A 2G/3G indicator in the Session Start message (which the GGSN passes transparently 
to the SGSN) indicates whether the content should be delivered in 2G-only or 3G-only (or both) coverage areas. 

e) The SGSN uses the 2G/3G indicator to decide whether a MBMS Session Start Request message should be sent 
to the BSCs and/or the RNCs. 

NOTE 2: See subclause 7.3 for potential issues. 

5.1 .5.3 Same MBMS Bearer Service for 2G and 3G for the same MBMS User 
Service 

The same MBMS user service may also transfer its data on the same MBMS bearer service for both 2G and 3G 
coverage. For this purpose one IP multicast addresses and the associated TMGI should be allocated for the same MBMS 
user service. In such application, the "different" 2G and 3G content for the same MBMS user service are sent in 
separate MBMS Sessions sequentially. The 2G/3G indicator in the Session Start message indicates whether the MBMS 
session should be delivered in 2G-only or 3G-only (or both) coverage areas. The SGSN uses the 2G/3G indicator to 
decide whether a MBMS Session Start Request message should be sent to the BSCs and/or the RNCs. 

5.1 .6 Location Dependent Content Transfer for the same MBMS User 
Service (Broadcast Mode only) 

Some MBMS user services may broadcast different content in different areas of the network. In such case the UE is not 
aware of the relation between location and content, i.e. the UE just activates the reception of the service and receives the 
content that is relevant for its location. 

The BM-SC controls which content is broadcasted in which area by establishing a separate MBMS bearer service for 
each content data flow. All MBMS bearer services of the same MBMS user service share the same TMGI but bear a 
different Flow Identifier. The BM-SC allocates the Flow Identifier during the MBMS Session Start procedure and 
initiates a separate session for each content data flow. Since in any specific location only one version of the content 
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shall be available at any point in time, the MBMS Service Areas of each session of a same user service shall not 
overlap; this shall be ensured by proper configuration of the service in the BM-SC. The RNC ultimately enforces this 
constraint by rejecting any session start request with the same TMGI as an already active session if there is any overlap 
in the respective service areas. As indicated above, the UE is unaware of the Flow Identifier and of the existence of 
multiple sessions for the same MBMS user service. 

5.2 User Equipment 

The UE shall support functions for the activation/deactivation of the MBMS bearer service. 

Once a particular MBMS bearer service is activated, no further explicit user request is required to receive MBMS data 
although the user may be notified that data transfer is about to start. 

The UE shall support security functions as appropriate for MBMS. 

The UE should, depending on terminal capabilities, be able to receive MBMS user service announcements, paging 
information (non MBMS specific) and support simultaneous services (for example the user can originate or receive a 
call or send and receive messages whilst receiving MBMS video content). Reception of this paging or announcements 
may however, create losses in the MBMS data reception. The MBMS user service should be able to cope with such 
losses. 

The UE shall be able to synchronise with the SGSN, which of its MBMS UE contexts are still active. 

Depending upon terminal capability, UEs may be able to store MBMS data. This may involve DRM but this is out of 
scope of this specification. 

The MBMS Session Identifier contained in the notification to the UE shall enable the UE to decide whether it needs to 
ignore the forthcoming transmission of MBMS session (e.g. because the UE has already received this MBMS session). 

5.3 UTRAN/GERAN 

UTRAN/GERAN are responsible for efficiently delivering MBMS data to the designated MBMS service area. 

Efficient delivery of MBMS data in multicast mode may require mechanisms in the UTRAN/GERAN, e.g. the number 
of users within a cell prior to and during MBMS transmission could be used to choose an appropriate radio bearer. 

MBMS transmissions may be initiated and terminated intermittently. The UTRAN/GERAN shall support the initiation 
and termination of MBMS transmissions by the core-network. Further, the UTRAN/GERAN shall be able to receive 
MBMS data from the core-network over lu bearers shared by many UEs. UTRAN (and GERAN in lu mode) may also 
support reception of MBMS data from the core-network over IP multicast. When UTRAN (or GERAN lu mode) 
supports IP multicast reception, the UTRAN (GERAN lu mode) should support TEID coordination, i.e. avoid using the 
same value ranges for its own unicast TEIDs as are used by the GGSN for the Common TEID-Us. If clashes anyhow 
occur, the RNC (lu mode BSC) shall reject IP multicast reception and fallback to normal shared lu bearers for reception 
of MBMS data. 

The UTRAN/GERAN shall support both intra-RNC/BSC and inter-RNC/BSC mobility of MBMS receivers. Mobility is 
expected to cause limited data loss. Therefore, MBMS user services should be able to cope with potential data loss 
caused by UE mobility. 

The UTRAN/GERAN shall be able to transmit MBMS user service announcements, paging information (non MBMS 
specific) and support other services in parallel with MBMS (for example depending on terminal capabilities the user 
could originate or receive a call or send and receive messages whilst receiving MBMS video content). 

5.4 SGSN 

The SGSN's role within the MBMS architecture is to perform MBMS bearer service control functions for each 
individual UE and to provide MBMS transmissions to UTRAN/GERAN. When IP multicast is used for MBMS 
transmissions the SGSN is bypassed in the 3G case (and GERAN lu mode case), i.e. MBMS data sent directly from 
GGSN to RNC (or lu mode BSC). 
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The SGSN shall provide support for intra-SGSN and inter-SGSN mobility procedures. Specifically this requires the 
SGSN to store a user-specific MBMS UE context for each activated multicast MBMS bearer service and to pass these 
contexts to the new SGSN during inter-SGSN mobility procedures. 

The SGSN shall be able to indicate its MBMS support to the UE as well as it shall be able to synchronise with the UE, 
which of the UE's MBMS UE contexts are still active. 

The SGSN shall be able to generate charging data per multicast MBMS bearer service for each user. The SGSN does 
not perform on-line charging for either the MBMS bearer service or the MBMS user service (this is handled in the BM- 
SC). 

The SGSN shall be able to establish lu and Gn bearers shared by many users upon receiving a session start from the 
GGSN. Likewise, the SGSN shall be able to tear down these bearers upon instruction from the GGSN. 

5.5 GGSN 



• 



• 



The GGSN role within the MBMS architecture is to serve as an entry point for IP multicast traffic as MBMS 
data. Upon notification from the BM-SC the GGSN shall be able to request the establishment of a bearer plane 
for a broadcast or multicast MBMS transmission. Further, upon BM-SC notification the GGSN shall be able to 
tear down the established bearer plane. Bearer plane establishment for multicast services is carried out towards 
those SGSNs and/or RNCs that have requested to receive transmissions for the specific multicast MBMS bearer 
service. For an optimized bearer plane, IP multicast transport may be used within the core network. The bearer 
plane is then established between the GGSN and the RNCs. 

When IP multicast is used for distribution payload from GGSN to RNC, and one or more RNC rejects IP 
multicast distribution, the GGSN should in parallel with the IP multicast distribution provide legacy MBMS 
payload distribution (i.e. using point-to-point GTP-tunnels) via the SGSNs to these RNCs. In that case, the 
GGSN shall remove the synchronisation protocol elements included by the BM-SC (i.e. synchronization 
information and the compressed header) before forwarding the payload on the legacy path (see TS 25.446 [16]). 

The GGSN shall be able to receive MBMS specific IP multicast traffic and to route this data to the proper IP 
multicast distribution address and/or GTP tunnels set-up as part of the MBMS bearer service. 



The GGSN may also provide features that support the MBMS bearer service that are not exclusive to MBMS. Examples 
are: 

Message Screening (not needed if the MBMS sources are internal in the PLMN); 

Charging Data Collection; 

Flow Based Charging (see section 10). 

5.6 MBMS Data Sources and Content Provider 

The reference point from the content provider to the BM-SC is not standardised by 3GPP in this release of the 
specification. 

5.7 Other Functional Element 

5.7.1 Void 

5.7.2 CBC 

The Cell Broadcast Centre (CBC) may be used to announce MBMS user services to the users. 
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5.7.3 Void 
5.8 Void 



6 MBMS Attributes and Parameters 

6.1 IVIBIVIS UE Context 

The MBMS UE Context contains UE-specific information related to a particular MBMS bearer service that the UE has 
joined. An MBMS UE Context is created in the UE, SGSN,GGSN and BM-SC Membership function when the UE 
joins an MBMS bearer service. In the SGSN, an MBMS UE Context is also created as a result of an inter-SGSN routing 
area update after the transfer of the MBMS UE Context from the old SGSN. 

In lu mode, all MBMS UE Contexts of a UE are provided via MBMS UE Linking mechanism to the BSC/SRNC at 
least when the first PS RAB is established for the UE, or when the UE performs MBMS Multicast Service Activation. 
MBMS UE Contexts are provided to the lu mode BSC/SRNC regardless whether MBMS Sessions are ongoing or not 
(i.e. before, between and after Sessions). In addition, all MBMS UE Contexts of a UE are provided via MBMS UE 
Linking mechanism when a UE, which has an MBMS UE Context active, moves to PMM-Connected state via the 
MBMS Service Request procedure for the purpose of MBMS. 

In the UE and SGSN, the MBMS UE Context is stored as part of the MM Context for the UE. The MBMS UE Context 
is stored in the GGSN. There is one MBMS UE Context per MBMS bearer service that the UE has joined. 

In the lu mode BSC/RNC, the MBMS UE Contexts are stored as part of the UE Context of the BSC/RNC. 

The content of the MBMS UE Context is described in Table 1 . 
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Table 1 : MBMS UE Context 



Parameter 


Description 


UE 


SGSN 


GGSN 


RNC 


BSC 


BM-SC 


IP multicast address 


IP multicast address identifying an 
MBMS bearer that the UE has joined. 


X 


X 


X 


X 


lu-X 
Gb - none 


X 


APN 


Access Point Name on which this IP 
multicast address is defined. 


X 


X 


X 


X 


lu-X 
Gb - none 


X 


GGSN Address in 
Use 


The IP address of the GGSN currently 
used 




X 










SGSN address 


The IP address of SGSN 






X 








TMGI 


Temporary Mobile Group Identity 
allocated to the MBMS bearer. 


X 


X 




X 


lu-X 
Gb - none 




RAI 


The Routing Area Identity 




(5) 










Linked NSAPI 


NSAPI of the PDP context used by 
the UE to carry IGMP/MLD signalling. 


X 


X 










IMSI 


IMSI identifying the user. 


(1) 


(1) 


X 


(2) 


lu - (2) 
Gb - (3) 


X 


Tl 


Transaction Identifier 


X 


X 










TEID for Control 
Plane 


The Tunnel Endpoint Identifier for the 
control plane between SGSN and 
GGSN. 




X 


X 








MBMS_NSAPI 


Network layer Service Access Point 
Identifier which identifies an MBMS 
UE Context. 


X 


X 


X 


X 






Additional MBMS 
Trace Info 


Identifies additional information 
required to perform trace. 




(4) 


(4) 






(4) 


Trace Reference 


Identifies a record or a collection of 
records for a particular trace. 




(4) 


(4) 


(4) 


(4) 




Trace Type 


Indicates the type of trace. 




(4) 


(4) 


(4) 


(4) 




Trigger Id 


Identifies the entity that initiated the 
trace. 




(4) 


(4) 


(4) 


(4) 




OMG Identity 


Identifies the OMC that shall receive 
the trace record(s). 




(4) 


(4) 


(4) 


(4) 




(1 ) In the UE and SGSN, the IMSI is available within the MM Context which contains the MBMS UE Context. 

(2) The IMSI is available within the UE Context which contains the MBMS UE Context. 

(3) IMSI availability does not depend on MBMS. 

(4) Trace parameters are only stored if trace is activated. 

(5) RAI is available within the MM Context of the UE. 



6.2 



MBMS Bearer Context 



The MBMS Bearer Context, which is referred to as MBMS Service Context in RAN, contains all information 
describing a particular MBMS bearer service and is created in each node involved in the delivery of the MBMS data. 

An MBMS Bearer Context is created in the SGSN and GGSN when the first MBMS UE Context is created in the node 
or when a downstream node requests it. The MBMS Bearer Context is statically configured in the BM-SC Proxy and 
Transport Function; how this is done is out of the scope of this specification. The MBMS Bearer Context is created in 
the lu mode BSC and in SRNC when a first MBMS UE Context is created in BSC/SRNC. MBMS Session Start 
procedure may create MBMS Bearer Context in a BSC/RNC which has no MBMS Bearer Context yet. 

An MBMS Bearer Context, once created, can be in one of two states reflecting the bearer plane resource status of the 
corresponding MBMS bearer service. 
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No bearer plane resources required 
Standby 




Session Start Y i Session Stop 



Bearer plane resources required 

Figure 6: MBMS Bearer Context State Model 

'Active' reflects the state of an MBMS Bearer Context in which bearer plane resources are required in the network for 
the transfer of MBMS data. This state is maintained as long as there is a corresponding MBMS session ongoing. 

'Standby' reflects the state of an MBMS Bearer Context in which no bearer plane resources are required in the network 
for the transfer of MBMS data. This state is maintained as long as there is no corresponding MBMS session ongoing. 

The content of the MBMS Bearer Context is described in Table 2. 
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Table 2: MBMS Bearer Context 



Parameter 


Description 


RAN 


SGSN 


GGSN 


BIVI-SC 


Multicast/broadcast 
mode 


MBMS bearer service in broadcast or multicast mode 


X 


X 


X 


X 


IP multicast address( 
multicast mode only) 


IP multicast address identifying the MBMS bearer 
described by this MBMS Bearer Context. 


X 


X 


X 


X 


APN 

(multicast mode only) 


Access Point Name on which this IP multicast address 
is defined. 


X 


X 


X 


X 


IMG! 


Temporary Mobile Group Identity allocated to the 
MBMS bearer service. 


X 


X 


X 


X 


Flow Identifier 
(broadcast mode 
only) 


Location dependent subflow of the MBMS bearer 
service. When present, the Flow Identifier together with 
the TMGI uniquely identify the MBMS Bearer Context. 




X 

(note 1) 


X 

(note 1) 


X 

(note1) 


GGSN TEID-G 


Tunnel Endpoint Identifier of GGSN for control plane. 




X 






GGSN IP Address for 
Control Plane in use 


The IP address of the GGSN used for the control plane. 




X 

(note 4) 






GGSN IP Address for 
User Plane in use 


The IP address of the GGSN used for the user plane. 




X 

(note 4) 






State 


State of bearer plane resources ('standby' or 'active') 


X 


X 


X 


X 


Required MBMS 
Bearer Capabilities 
(multicast mode only) 


Minimum bearer capabilities the UE needs to support 




X 


X 


X 


QoS 


Quality of Service required for the MBMS bearer 
service. 


X 


X 


X 


X 


MBMS Service Area 


Area over which the MBMS bearer service has to be 
distributed. 


X 


X 


X 


X 


List of downstream 
nodes 


List of downstream nodes that have requested the 
MBMS bearer service and to which notifications and 
MBMS data have to be forwarded. 




X 

(note 5) 


X 

(notes 
3, 4,6) 


X 


Number of UEs 
(multicast mode only) 


Number of UEs hosted by the node that have joined the 
multicast MBMS bearer service. 




X 


X 




List of PMM- 
CONNECTED UEs 


List of PMM-CONNECTED UEs which have activated 
an MBMS service. 


X 

(note 2) 








List of RAs 
(multicast mode only) 


List of RAs, each of which contains at least one UE that 
has joined the MBMS bearer service. 


X 

(note1) 


X 

(note 1) 






IP multicast and 
Source address for 
distribution 


IP addresses identifying the SSM channel used for user 
plane distribution on the backbone network 


X 


X 


X 




MBMS HC indicator 


Flag set by BM-SC if it is using compressed header for 
the payload. 




X 


X 


X 


NOTE 1 : It is an optional parameter. 

NOTE 2: It is available only for UTRAN, not for GERAN. 

NOTE 3: For GGSN, the list at least includes the couples of the SGSN IP addresses and TElDs for control plane, and the 

couples for user plane. 
NOTE 4: GSN that supports both IPv4 and IPv6 address types, stores only the IP address in use. 
NOTE 5: For SGSN, the list includes the registered DRNC. 
NOTE 6: The GGSN shall include SGSN Address for user data and TEID-U for downstream SGSNs that do not accept 

the IP multicast backbone distribution. 



6.3 Quality-of-Service 



It shall be possible for the network to control quality-of-service parameters for sessions of multicast and broadcast 
MBMS bearer services. All QoS attributes related to the UMTS bearer service described in TS 23.107 [3] are applicable 
to MBMS bearer services. Compared to point-to-point bearer services the following limitations exist: 

For traffic class, only the background and streaming classes shall be supported. 

For SDU error ratio, only higher values are supported, i.e. the values describing higher numbers of lost or 
corrupted SDUs (actual values are for the background and streaming classes are 10"^ and 10"'). 

For maximum bit-rate, see the values described in TS 22.246 [6]. 

For Guaranteed bit rate of the Streaming Traffic Class: depending on radio resource usage by other services, 
some cells of the MBMS Service Area may not have sufficient resources available for a MBMS Session. The 
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RAN may decide not to establish RB in cells where requested resources are not available. The RAN does not 
reject a MBMS Session Start Request message even if one or more cells do not have enough resources to 
establish radio bearers. 

MBMS bearer services of background class are best suited for the transport of MBMS user services such as messaging 
or downloading. Buffering, shaping schemes and packet dropping may be applied to the traffic flow to adapt to the 
available resources and changing network conditions. The total transfer time is not critical for background class bearer 
services since the content must normally have been received in totality and stored in the UE before the user can access 
it. 

MBMS bearer services of streaming class are best suited for the transport of MBMS user services such as streaming. As 
for point-to-point bearer services, the network should minimise the packet transfer delay of streaming class bearer 
services as far as possible. Packet dropping should be the preferred traffic conditioning action applied to the traffic flow 
to adapt to the available resources. 

The principle difference between background and streaming classes for MBMS is the support of a guaranteed bit-rate in 
the streaming case. No indication is provided to the UE in cases where the RAN cannot provide the requested QoS. As a 
result, some UEs may not receive the MBMS session or parts of it. For background class, the RAN may continue to 
distribute data in congestion conditions but at potentially high packet loss rates, therefore the MBMS user service will 
have to provide sufficient redundancy within the data to be able to cope with the high packet loss. 

MBMS user services that would normally use MBMS bearer services of background class may however decide to use a 
streaming class MBMS bearer service if the MBMS user service cannot cope with high packet loss. 

The Allocation and Retention Priority of the MBMS bearer service allows for prioritisation between MBMS bearer 
services, and between MBMS bearer services and non MBMS bearer services. 

As the MBMS bearer service transfers data to many UEs in parallel and because of the lack of feedback channel on 
radio level low SDU error ratios are difficult to achieve. When the resulting packet error ratio is not suitable for the 
MBMS user service or when prevention of data loss is required, an MBMS user service may perform retransmission of 
MBMS data over a point-to-point PDP context. 

6.3.1 MBMS QoS distribution tree 

MBMS data will be distributed to multiple users through a MBMS distribution tree that can go through many 
BSCs/RNCs, many SGSNs and one or more GGSNs. Furthermore some bearer resources may be shared between many 
users accessing the same MBMS bearer service in order to save resources. As a result, each branch of a MBMS 
distribution tree shall be established with the same QoS. 

MBMS distribution tree shall have the same QoS for all its branches. 

When a branch of the MBMS distribution tree has been created, it is not possible for another branch (e.g. due to arrival 
of a new UE or change of location of a UE with removal of a branch and addition of a new one) to impact the QoS of 
already established branches. 

There is no QoS (re-)negotiation between network elements (e.g. between RNC and SGSN). This implies that some 
branches may not be established if QoS requirement cannot be accepted by the concerned network node. 



6.4 Temporary Mobile Group Identity 



Temporary Mobile Group Identity (TMGI) is used for MBMS notification purpose. The BM-SC allocates a globally 
unique TMGI per MBMS bearer service. The structure of the TMGI is defined in TS 23.003 [13]. 

For Multicast MBMS bearer services the TMGI is transmitted to UE via the MBMS Multicast Service Activation 
procedure. For Broadcast Service the TMGI can be obtained via service announcement see " Service Announcement". 

The TMGI is a radio resource efficient MBMS bearer service identification, which is equivalent to the MBMS bearer 
service identification consisting of IP multicast address and APN. 
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6.5 IP Multicast distribution 

In GGSN it shall by configuration be possible enable distribution of MBMS payload by using IP Multicast in the 
backbone network. IP Multicast distribution is done from GGSN to RNC downstream nodes. The Source Specific 
Multicast (SSM) service model shall be used by nodes and routers as specified in RFC 4607 [19] and RFC 4604 [20]. 
Fallback to legacy point-to-point distribution is done for nodes which do not support IP Multicast distribution. 

The GGSN chooses an IP Multicast address for distribution and a Source address as well as a common TEID-U. The 
proposed IP Multicast and Source address for distribution and the common TEID-U is indicated by the GGSN to the 
downstream SGSNs at Session Start. The SGSN forwards the request to the downstream RNC (and BSC in lu mode) at 
Session Start. The RNC may accept or reject the proposed IP Multicast distribution in the MBMS Session Start 
Response to the SGSN. If accepted the RNC shall report the channel (IP Multicast and Source address) to the backbone 
in order to join the bearer service multicast distribution. At Session Stop the RNC shall correspondingly report to the 
backbone in order to leave the bearer service multicast distribution. 

If one or more downstream RNC nodes do not accept IP Multicast distribution, the SGSN will establish a normal 
MBMS point-to-point GTP-U tunnel to related RNCs and a point-to-point GTP-U tunnel to the GGSN. The SGSN does 
not respond to the GGSN until it has received responses from all RNCs. The SGSN shall indicate to the GGSN if IP 
Multicast distribution is accepted (by one or more RNCs) and it shall also indicate if normal MBMS point-to-point 
distribution is required (by one or more RNCs). The SGSN will also establish a normal MBMS point-to-point GTP-U 
tunnel to GGSN if there are BSCs in Gb mode in the MBMS distribution tree. 

The RNC node shall indicate to SGSN if IP Multicast distribution is accepted in the Session Start Response. If this 
indication is missing, the SGSN node shall treat the RNC node as not accepting IP Multicast distribution and use 
unicast distribution. 

IP Multicast distribution is only used within a PLMN. In the roaming case the GGSN establishes normal MBMS point- 
to-point GTP-U tunnels to SGSNs/RAN nodes in other networks. 

GGSN shall assign IP Multicast addresses used for MBMS distribution according to RFC 4607 [19]. When several 
GGSN are used for MBMS payload distribution, the used IP Multicast addresses and common TEIDs shall be 
coordinated by configuration. Clashes between common TEIDs allocated by GGSN and TEIDs allocated by RNC 
should be avoided by coordinated TEID ranges. 

The GTP-U Error Indication mechanism shall be disabled for MBMS bearers using IP Multicast distribution. The 
receiving node controls itself what is received using the IGMPv3/MLDv2 protocol, RFC 4604 [20]. 

The MBMS payload with the synchronization information received from the BM-SC included, shall be distributed by 
the GGSN with IP Multicast to the RNC. The synchronization information is used in the radio interface for the user data 
transmission synchronization across the RNCs as described in TS 25.346 [10]. It is up to RAN configurations whether 
the inter-RNC MBMS combining/MBSFN operation mode is used during the MBMS payload delivery. 



7 Architectural Aspects of MBMS User Services 

MBMS bearers may be used in numerous ways to provide different types of applications. MBMS user services employ 
MBMS bearers and possibly point-to-point bearers in order to provide application data in an efficient manner. This 
section is used to discuss different aspects of MBMS user services that directly relate to the usage of MBMS and point- 
to-point bearers. This section is not intended to deal with the architecture and interfaces of MBMS user services. 

7.1 Alternative User Service Support 

For many MBMS services, it will be necessary to provide alternative means for the UE to access the service without 
using MBMS bearer capabilities. This is required, for example, after completion of the MBMS session for a file 
download to permit errors in the file to be corrected; to permit the network to charge for a successful download; to pass 
a decrypt key to the UE; etc. It may also be useful in cases where all or part of an MBMS transmission has been missed 
due to the UE being out of coverage, switched off, etc. 

Care is needed to ensure that such alternative access mechanisms do not create traffic that overloads the network (radio, 
RNC, BSC, SGSN, GGSN and BM-SC). In the case that such alternative access requires direct interaction between the 
UE and a network server, one way for this load to be distributed is for the BM-SC to distribute to each UE, at activation 
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time, one or more server addresses (from a group of addresses), along with parameter(s) that are used to generate a 
random time dispersion of the requests. 

7.2 Avoid overload in SGSN, GGSN and BIVI-SC caused by 
Joining 

For Joining that is triggered by a service announcement (e.g. CBS or MBMS), then the service announcement needs to 
be able to contain parameters to help avoid overload in the SGSN, GGSN and BM-SC. The UE uses the defined 
parameters in the service announcement to randomly select the time at which to join the service. Hence the BM-SC 
needs to be able to generate the parameters and needs to be able to get them sent to the UE in the service announcement. 

7.3 Access aspects of IVIBIVIS user services 

In networks with multiple accesses, e.g. GERAN and UTRAN, users may in some situations experience problems in 
receiving MBMS services. These situations include: 

an operator that has chosen to provide a service on one access only (e.g. only on GERAN), and where a UE is 
camping on the wrong access (i.e. on UTRAN in the previous example) when an MBMS session is started. This 
UE may miss the MBMS content, as the MBMS architecture doesn't provide any mechanism for paging 
coordination, etc. 

an operator that has chosen to provide a service with different QoS levels on GERAN and UTRAN (see 
subclause 5.1.5.2). A UE that is changing access type during an ongoing MBMS session may not be able sort the 
situation out and receive the MBMS content correctly. 



8 IVIBIVIS Procedures 

8.1 MBMS Notification 

8.1 .1 lu mode notification (UTRAN and GERAN) 

When an MBMS Session starts, UEs interested in the MBMS bearer service (PMM-CONNECTED UEs and PMM- 
IDLE UEs) shall be notified. 

MBMS Session attributes such as Session Identifier and MBMS Service Area(s) are made available in all interested 
RNCs during the Session Start procedure. 

For radio efficiency reasons, the UTRAN may select on a per cell basis whether to establish point-to-point or point-to- 
multipoint links for the distribution of MBMS data to the UEs. 

In order to perform this selection, the UTRAN requests a proportion of UEs to move to PMM-CONNECTED mode by 
means of MBMS notification sent in the MBMS service Area. 

The exact number of UEs moved to PMM-CONNECTED mode is a decision of the RAN node. It is not necessary for 
all UEs to move to PMM-CONNECTED mode in order for the RAN to decide to use point-to-multipoint, other UEs 
may remain in PMM-IDLE state. This is a UTRAN choice (based on Radio Resource Management criteria). 

Following the decision to set up point-to-point or point- to -multipoint links, the number of UEs that need to be 
maintained in PMM-CONNECTED mode or moved to PMM-IDLE mode for MBMS data reception is also a decision 
of the RAN node. 

8.1 .2 A/Gb mode notification (GERAN) 

When an MBMS Session starts, UEs interested in the MBMS bearer service and that are in READY or STANDBY 
states shall be notified. The MBMS notification triggers detection or counting of UEs per cell for selection of the most 
appropriate MBMS radio bearer. 
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MBMS Session attributes such as Session Identifier, MBMS Service Area, QoS are made available in all interested 
BSCs that are connected to a registered SGSN by the Session Start procedure. 



8.2 



MBMS Multicast Service Activation 



The MBMS multicast service activation procedure registers the user in the network to enable the reception of data from 
a specific multicast MBMS bearer service. The activation is a signalling procedure between the UE and the network. 
The procedure establishes MBMS UE contexts in UE, SGSN and GGSN and lu mode BSC/RNC for each activated 
multicast MBMS bearer service comparable to regular PDP contexts. 



UE 



RAN 



l.PDPConte 



2.TGMP.Tnin 



5. Request MBIV S Context Activi tion 



6. Activate MB]\ [S Context Reque st 



8. Security Functions 



15. 



SGSN 



t Activation 



9. Invoke Trace 
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4a. MBMS Notificati( n Request 
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12.MBMS Registration Request 
12. MBMS Registration Responsfe 



Figure 7: The activation of an IVIBIVIS multicast service 

1 . The UE activates a general purpose PDP context if one is not already established. 

2. The UE sends an IGMP (IPv4) or MLD (IPv6) Join message over the default PDP context to signal its interest in 
receiving a particular multicast MBMS bearer service identified by an IP multicast address. 

3. The GGSN sends an MBMS Authorization Request seeking authorization for the activating UE to receive data. 
The MBMS Authorization Request may include trace information (Additional MBMS Trace Info), if activated. 
The authorization decision, which may be based on subscription data in the BM-SC, Membership function is 
provided in the MBMS Authorization Response together with the APN to be used for creation of the MBMS UE 
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context. If the MBMS Authorization Response indicates that the UE is not authorized to receive the MBMS data 
the process terminates with no additional message exchange. 

4a. The GGSN sends an MBMS Notification Request (IP multicast address, APN, Linked NSAPI) to the SGSN. 
Linked NSAPI is set equal to the NSAPI of the PDP context over which the Join request was received. The IP 
multicast address is the one requested by the UE in the Join request. The APN may be different from the APN to 
which the default PDP context has been activated. In any case, the APN may resolve to a GGSN that is different 
from the GGSN receiving the IGMP/MLD Join request. The GGSN starts a MBMS Activation Timer as GGSN 
may receive no response, e.g. in case SGSN or UE does not support MBMS. 

4b. The SGSN sends a MBMS Notification Response (Cause) to the GGSN that sent the MBMS Notification 

Request, where Cause shall indicate whether or not the MBMS context activation will proceed. Upon reception 
of the response message with Cause indicating unsuccessful operation the GGSN should not send any further 
MBMS Notification Request messages. The procedure is then terminated. 

5. The SGSN sends a Request MBMS Context Activation (IP multicast address, APN, Linked NSAPI, TI) to the 
UE to request it to activate an MBMS UE Context. Linked NSAPI allows the UE to associate the MBMS UE 
Context with the PDP context over which it sent the IGMP/MLD Join message in step 2. TI was chosen by the 
SGSN and contains a value not used by any other activated PDP context and MBMS UE context for this UE. 

6. The UE creates an MBMS UE context and sends an Activate MBMS Context Request (IP multicast address, 
APN, MBMS_NSAPI, MBMS bearer capabilities) to the SGSN. The IP multicast address identifies the MBMS 
multicast service, which the UE wants to join/activate. An APN may indicate a specific GGSN. The MBMS 
bearer capabilities indicate the maximum QoS the UE can handle. The MBMS_NSAPI was chosen by the UE 
and contains a value not used by any other activated PDP context and MBMS UE context for this UE. If the 
SGSN has the MBMS Bearer Context information for this MBMS bearer service, the SGSN should verify the 
UE's MBMS bearer capabilities. If the SGSN determines that the UE's MBMS bearer capabilities are less than 
the Required MBMS Bearer Capabilities, it shall reject the request for activation of an MBMS context with an 
appropriate cause. 

7. If the MBMS UE Context was not established, the SGSN sends a MBMS Notification Reject Request (Cause) to 
the GGSN that sent the MBMS Notification Request, where Cause shall indicate the reason why the MBMS UE 
Context could not be established. The GGSN then sends a MBMS Notification Reject Response back to the 
SGSN. This should prevent further sending of MBMS Notification Request messages. The procedure is then 
terminated. 

8. Security Functions may be performed, e.g. to authenticate the UE. 

9. In A/Gb mode and if BSS trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, 
Trigger Id, and OMC Identity) message to the BSS. Trace Reference, and Trace Type are copied from the trace 
information received from the HLR or OMC. 

10. The SGSN creates an MBMS UE context and sends a Create MBMS Context Requests (IP multicast address, 
APN, MBMS_NSAPI, IMSI, MSISDN, RAI, IMEI-SV, RAT Type, MS Time Zone, CGI/SAI, Trace Reference, 
Trace Type, Trigger Id, OMC Identity , Additional MBMS Trace Info) to the GGSN. The SGSN shall include 
Trace Reference, Trace Type, Trigger Id, and OMC Identity if GGSN trace is activated. The SGSN shall include 
Additional MBMS Trace Info if BM-SC trace is activated. The SGSN shall copy Trace Reference, Trace Type, 
and OMC Identity from the trace information received from the HLR or OMC. The inclusion of CGI/SAI shall 
be according rules detailed in sub-clause 15.1.1a in TS 23.060 [15]. 

11. The GGSN sends an MBMS Authorization Request (IMSI, MSISDN, RAI, IMEI-SV, RAT Type, MS Time 
Zone, CGI/SAI, Additional MBMS Trace Info) seeking authorization for the activating UE. The GGSN shall 
include Additional MBMS Trace Info if BM-SC trace is activated. The CGI/SAI is included, if available. The 
authorization decision is provided in the MBMS Authorization Response. The BM-SC creates an MBMS UE 
Context. 

12. If the GGSN does not have the MBMS Bearer Context information for this MBMS bearer service, the GGSN 
sends a MBMS Registration Request to the BM-SC. See subclause "MBMS Registration Procedure". 

If no TMGI has been allocated for this MBMS bearer service, the BM-SC will allocate a new TMGI. This TMGI 
will be passed to GGSN and SGSN via the MBMS Registration Response message and further to UE via 
Activate MBMS Context Accept message. 
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The BM-SC responds with a MBMS Registration Response containing the MBMS Bearer Context information 
for this MBMS bearer service and adds the identifier of the GGSN to the "Hst of downstream nodes" parameter 
in its MBMS Bearer Context. See subclause "MBMS Registration Procedure". 

13. The GGSN creates an MBMS UE context and sends a Create MBMS Context Response to the SGSN. 

14. If the SGSN does not have the MBMS Bearer Context information for this MBMS bearer service, the SGSN 
sends a MBMS Registration Request to the GGSN. See subclause "MBMS Registration Procedure". 

The GGSN responds with a MBMS Registration Response containing the MBMS Bearer Context information 
for this MBMS bearer service and adds the identifier of the SGSN to the "list of downstream nodes" parameter in 
its MBMS Bearer Context. See subclause "MBMS Registration Procedure". 

15. The SGSN provides lu mode RAN with the MBMS UE Context(s) if at least one PS RAB is established for the 
UE. 

16. In lu mode and if trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, Trigger 
Id, and OMC Identity) message to the RAN. Trace Reference, and Trace Type are copied from the trace 
information received from the HLR or OMC. 

NOTE: Step 16 is applied when the trace activation is triggered by means of signalling. Another alternative is the 
triggering of trace activation by the OMC. The details of both Trace Activation procedures are described 

in TS 32.422 [14]. 

17. The SGSN sends an Activate MBMS Context Accept (TMGI) to the UE. If it was not possible to verify the UE's 
MBMS bearer capabilities in Step 6, the UE's MBMS bearer capabilities shall be verified now b y the SGSN. If 
the SGSN determines that the UE's MBMS bearer capabilities are lower than the Required MBMS Bearer 
Capabilities the SGSN rejects the request for activation of an MBMS context indicating an appropriate cause and 
starts the deactivation of the already established MBMS UE contexts. 

8.2.1 Void 



8.3 MBMS Session Start Procedure 

8.3.1 IVIBIVIS Session Start Procedure for GERAN and UTRAN 

The BM-SC initiates the MBMS Session Start procedure when it is ready to send data. This is a request to activate all 
necessary bearer resources in the network for the transfer of MBMS data and to notify interested UEs of the imminent 
start of the transmission. 

Through this procedure, MBMS session attributes such as QoS, MBMS service Area, estimated session duration, time 
to MBMS data transfer, are provided to the registered GGSN(s) and SGSN(s) and to all BSCs/RNCs that are connected 
to a listed SGSN. In addition the procedure allocates the bearer plane to all registered GGSNs and all registered SGSNs 
and to BSCs/RNCs that respond to the session start request message. 

After sending the Session Start Request message the BM-SC waits for a configurable delay (time to MBMS data 
transfer) before sending MBMS data. This delay should be long enough to avoid buffering of MBMS data in entities 
other than the BM-SC, i.e. the delay should allow the network to perform all procedures required to enable MBMS data 
transfer before the BM-SC sends MBMS data. For example notification of UEs and radio bearer establishment should 
be performed before MBMS data arrive in the RAN. The delay may be in the region of multiple seconds or tens of 
seconds. It may be useful for the BM-SC to be able to configure different delays for MBMS bearer services on 2G and 
3G, respectively. 

For multicast MBMS bearer services the registration of SGSNs and GGSNs is initiated by MBMS multicast Service 
Activation procedures. Inter SGSN Routeing Area Update procedures. Inter SGSN Serving RNS Relocation procedure 
and performed by MBMS Registration procedures. The GGSN keeps track of the registered SGSNs in the list of 
downstream nodes. 

For broadcast MBMS bearer services the list of downstream nodes of BM-SC and GGSN are achieved in the following 
ways: 
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The list of downstream nodes for GGSN will be sent from the BM-SC to the GGSN in the Session Start Request. 

Normally, the GGSN contained in the "list of downstream nodes" for BM-SC is the default GGSN (or two for 
resilience). 

The overall Session Start procedure is presented in the following figure: 
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Figure 8: Session Start procedure for GERAN and UTRAN 



2. 



The BM-SC Session and Transmission function sends a Session Start Request message to indicate the impending 
start of the transmission and to provide the session attributes (TMGI, Flow Identifier (Broadcast only), QoS, 
MBMS service Area, Session identifier, estimated session duration, broadcast/multicast, list of downstream 
nodes for GGSN (Broadcast only), time to MBMS data transfer, MBMS HC indicator (if header compression is 
used for MBMS payload), ...) and the 2G/3G indicator. The message is sent to the BM-SC Proxy and Transport 
function, which then forwards it to the GGSNs listed in the "list of downstream nodes" parameter of the 
corresponding MBMS Bearer Context. The BM-SC Proxy and Transport function sets the state attribute of its 
MBMS Bearer Context to 'Active'. For a broadcast MBMS bearer service the GGSN creates an MBMS bearer 
context. In broadcast mode, the BM-SC may start multiple sessions for the same MBMS bearer service 
(identified by the TMGI) but with different content. If so, a Flow Identifier is included in the Session Start 
Request to identify the different sub-sessions and the associated MBMS Service Areas shall not overlap. The 
GGSN stores the session attributes and the list of downstream nodes in the MBMS Bearer Context, sets the state 
attribute of its MBMS Bearer Context to 'Active' and sends a Session Start Response message to the BM-SC. 
Proxy and Transport function which forwards it to the BM-SC Session and Transmission function. The BM-SC 
Proxy and Transport function copies Session Start Requests to the BM-SC Membership function for charging 
purposes. 

The GGSN sends an MBMS Session Start Request message containing the session attributes (TMGI, Flow 
Identifier (Broadcast only), QoS, MBMS service Area, Session identifier, estimated session duration, 
broadcast/multicast, time to MBMS data transfer, IP Multicast and Source addresses for backbone distribution, 
common TEID-U, MBMS HC indicator ...) and the 2G/3G indicator to the SGSNs listed in the "Hst of 
downstream nodes" parameter of the corresponding MBMS Bearer Context. For a broadcast MBMS bearer 
service the SGSN creates an MBMS bearer context. The SGSN stores the session attributes and the 2G/3G 
indicator in the MBMS Bearer Context, sets the state attribute of its MBMS Bearer Context to 'Active'. If one or 
more of the downstream nodes accepts the Session Start and the proposed IP Multicast and Source address for 
backbone distribution and the proposed common TEID-U, the SGSN includes an indication that IP Multicast 
distribution is accepted in the MBMS Session Start Response message to GGSN. If one or more of the 
downstream nodes does not accept the proposed IP Multicast and Source address for backbone distribution or the 
proposed common TEID-U or if there are downstream BSCs in Gb mode connected to the SGSN, the SGSN 
falls back to normal point-to-point MBMS bearer establishment for these nodes and responds with an MBMS 
Session Start Response message providing the TEID for bearer plane that the GGSN shall use for forwarding the 
MBMS data. Otherwise if all nodes accept multicast, the SGSN returns the common TEID-U and the IP 
Multicast distribution address in the Session Start Response message. The GGSN shall initiate IP Multicast 
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distribution if at least one of the SGSNs indicates it has accepted IP Multicast distribution. For MBMS bearer 
service a SGSN receiving multiple MBMS Session Start Request messages establishes only one bearer plane 
with one GGSN. 

3. The SGSN sends an MBMS Session Start Request message including the session attributes (TMGI, QoS, 
MBMS service Area, Session identifier, estimated session duration, broadcast/multicast, time to MBMS data 
transfer, Hst of RAs, MBMS HC indicator . . .) to each BSC and/or each RNC that is connected to this SGSN. 
When the message is sent to an RNC/BSC in lu mode, the IP Multicast and Source address for backbone 
distribution and common TEID-U shall also be included if received from the GGSN. The 2G/3G indicator shall 
be used by the SGSN to determine whether the MBMS Session Start Request message is sent only to BSCs, or 
only to RNCs, or to both RNCs and BSCs. For a broadcast MBMS bearer service the BSC/RNC creates an 
MBMS Service Context. The BSC in lu mode/RNC stores the session attributes in the MBMS Service Context, 
sets the state attribute of its MBMS Service Context to 'Active'. If the RNC accepts the Session start and the 
proposed IP Multicast and Source address for backbone distribution and the proposed common TEID-U the RNC 
sends an MBMS Session Start Response message to SGSN including an indication that IP Multicast distribution 
is accepted. If an RNC does not accept the proposed IP Multicast and Source address for backbone distribution 
(or the proposed common TEID-U), the RNC falls back to normal point-to-point MBMS bearer establishment A 
BSC in Gb mode which does not serve the MBMS Service Area need not store the session attributes. A 
BSC/RNC receiving multiple MBMS Session Start Request messages establishes only one bearer plane with one 
SGSN. 

3a. If the RNC accepts IP Multicast distribution the RNC joins the multicast group in the IP backbone according to 
RFC 3376 [17], RFC 3810 [18] and RFC 4604 [20]. 

4. The BSC/RNC establishes the necessary radio resources for the transfer of MBMS data to the interested UEs. 
RAN resource set up can be scheduled according to the time to MBMS data transfer parameter. 

NOTE: The upstream node normally provides the MBMS Session Start Request message once per MBMS 
session to a downstream node. Due to "Intra Domain Connection of RAN Nodes to Multiple Core 
Network Nodes" however, a BSC/RNC may receive the MBMS Session Start Request message from 
several SGSNs. 

8.3.2 Void 



8.4 MBMS Registration Procedure 

The MBMS Registration is the procedure by which a downstream node informs an upstream node that it would like to 
receive session attributes and data for a particular MBMS bearer service in order to distribute it further downstream. 
This procedure builds up a distribution tree for the delivery of MBMS session attributes and data from the BM-SC to 
the UEs interested in the service. This procedure results in the set-up of a corresponding MBMS Bearer Context in the 
nodes along the distribution tree, but it does not result in the establishment of bearer plane which will be established by 
the Session Start procedure. 

The MBMS Registration procedure is initiated: 

- When the first MBMS UE Context for a particular MBMS bearer service is created in the SGSN or GGSN (see 
subclause "MBMS UE Context") and the corresponding MBMS Bearer Context is not already established in the 
node; 

When an MBMS Registration Request for a particular MBMS bearer service is received from a downstream 
node but the corresponding MBMS Bearer Context is not established in the node; or 

When a DRNC detects that it hosts UEs interested in the MBMS bearer service. 

NOTE: The terms 'downstream' and 'upstream' refer to the topological position of one node with respect to 
another and relative to the direction of the MBMS data flow, i.e. from BM-SC to UE. 
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Figure 9: MBMS Registration procedure 

1. Wiien the DRNC detects that it hosts UEs interested in the MBMS bearer service, the DRNC sends a MBMS 
Registration Request message to its parent SGSN if not already done. How the RNC determines its parent SGSN 
is a matter of implementation. 

2. If the SGSN has no MBMS Bearer Context for an MBMS bearer service and the SGSN receives an MBMS 
Registration Request from an RNC for this MBMS bearer service, or if the first MBMS UE Context is created in 
the SGSN for an MBMS bearer service for which the SGSN has no corresponding MBMS Bearer Context, the 
SGSN creates an MBMS Bearer Context (in "Standby" state) and sends an MBMS Registration request (IP 
multicast address, APN) message to the GGSN. How the SGSN selects a GGSN is a matter of implementation; it 
may for instance be based on prior signalling related to a particular UE or via APN resolution. 

3. If the GGSN has no MBMS Bearer Context for an MBMS bearer service and the GGSN receives an MBMS 
Registration from an SGSN for this MBMS bearer service, or when the first MBMS UE Context is created in the 
GGSN for an MBMS bearer service for which the GGSN has no MBMS Bearer Context, the GGSN creates an 
MBMS Bearer Context (in "Standby" state) and sends a Registration Request (IP multicast address, APN) 
message to the BM-SC. Proxy and Transport function The exact nature of the signalling between GGSN and 
BM-SC via Gmb interface is specified in TS 29.061 [4]. 

4. Upon reception of an MBMS Registration Request from a GGSN, the BM-SC Proxy and Transport function 
adds the identifier of the GGSN to the "list of downstream nodes" parameter in its MBMS Bearer Context and 
responds with a MBMS Registration Response (TMGI, Required Bearer Capabilities) message. The exact nature 
of the signalling between GGSN and BM-SC via Gmb interface is specified in TS 29.061 [4]. If the MBMS 
Bearer Context is in the 'Active' state, the BM-SC initiates the Session Start procedure with the GGSN, as 
described in clause "MBMS Session Start Procedure". 

5. If the GGSN receives a Registration Request from the SGSN in step 2, the GGSN: 

adds the identifier of the SGSN to the "list of downstream nodes" parameter in its MBMS Bearer Context, 

responds with an MBMS Registration Response (TMGI, Required Bearer Capabilities) message, and 

if the MBMS Bearer Context is in the 'Active' state, initiates the Session Start procedure with the SGSN, as 
described in clause "MBMS Session Start Procedure". 

6. If the SGSN received MBMS Registration Request from the DRNC in step 1, the SGSN: 

adds the identifier of the RNC to the "list of downstream nodes" parameter in its MBMS Bearer Context, 

responds with an MBMS Registration Response message, and 

if the MBMS Bearer Context is in the 'Active' state, initiates the Session Start procedure with the DRNC, as 
described clause "MBMS Session Start Procedure". 



£75/ 



3GPP TS 23.246 version 8.4.0 Release 8 



36 



ETSI TS 123 246 V8.4.0 (2009-06) 



8.5 MBMS Session Stop Procedure 

8.5.1 MBMS Session Stop Procedure for GERAN and UTRAN 

The BM-SC Session and Transmission function initiates the MBMS Session Stop procedure when it considers the 
MBMS session to be terminated. The session is typically terminated when there is no more MBMS data expected to be 
transmitted for a sufficiently long period of time to justify a release of bearer plane resources in the network. The 
procedure is propagated to all SGSNs and GGSNs that are registered for the corresponding MBMS bearer service and 
to BSCs/RNCs that have an established lu bearer plane with an SGSN. 

The overall MBMS Session Stop procedure is presented in the following figure: 
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Figure 10: MBMS Session Stop procedure for GERAN and UTRAN 

1. The BM-SC Session and Transmission function sends a Session Stop Request message to the BM-SC Proxy and 
Transport function, which forwards it to all GGSNs listed in the "list of downstream nodes" parameter of the 
affected MBMS Bearer Context to indicate that the MBMS session is terminated and the bearer plane resources 
can be released. The MBMS Bearer Context is uniquely identified by the TMGI or the combination of TMGI 
and Flow Identifier. The BM-SC Proxy and Transport function sets the state attribute of its MBMS Bearer 
Context to 'Standby'. The GGSN sends a Session Stop Response message to the BM-SC Proxy and Transport 
function, which forwards it to the BM-SC Session and Transmission function. The BM-SC Proxy and Transport 
function copies Session Stop Requests to the BM-SC Membership function for charging purposes. 

2. The GGSN sends an MBMS Session Stop Request message to all SGSNs that have a bearer plane established 
with the GGSN, releases the corresponding bearer plane resources towards these SGSNs and sets the state 
attribute of its MBMS Bearer Context to 'Standby'. The GGSN releases the MBMS Bearer Context in case of a 
broadcast MBMS bearer service. 

3. The SGSN releases the TEID and bearer plane resources on which it was receiving MBMS data from the GGSN 
for the affected MBMS bearer service and sends an MBMS Session Stop Request message to all BSCs/RNCs 
that have a bearer plane established with the SGSN and sets the state attribute of its MBMS Bearer Context to 
'Standby'. The SGSN releases the MBMS Bearer Context in case of a broadcast MBMS bearer service. 

3a If the RNC/BSC is using IP multicast distribution it shall disable reception from the IP backbone of the 
particular MBMS bearer service according to RFC 3376 [17], RFC 3810 [18] and RFC 4604 [20]. 

4. The RNC releases the affected radio and lu resources; the BSC releases the affected radio resources. The 
BSC/RNC sets the state attribute of its MBMS Bearer Context to 'Standby'. The BSC/RNC releases the MBMS 
Service Context in case of a broadcast MBMS bearer service. A BSC in Gb mode shall send an 
acknowledgement to the SGSN even if there is no active MBMS context in the BSC. 
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8.5.2 Void 



8.6 MBMS De-Registration Procedure 
8.6.0 Common IVIBIVIS De-Registration procedure 

The MBMS De-Registration is the procedure by which a downstream node informs an upstream node that it does not 
need to receive signalHng, session attributes and data for a particular MBMS bearer service anymore and therefore 
would like to be removed from the corresponding distribution tree. 

The MBMS De-registration procedure is initiated: 

- By the SGSN or GGSN when the last MBMS UE Context for a particular MBMS bearer service is deleted from 
the node and the "list of downstream nodes" parameter in the corresponding MBMS Bearer Context is empty; 

By the SGSN or GGSN when the last node registered in the "list of downstream nodes" de-registers from an 
MBMS bearer service for which there is no corresponding MBMS UE Context; or 

- By the DRNC that registered at an SGSN when it deletes the associated MBMS Service Context. 
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Figure 11: MBMS De-Registration Procedure 

When the DRNC that is registered at an SGSN no longer hosts any UE interested in that MBMS bearer service, 
the DRNC requests the de-registration from the MBMS bearer service to its parent SGSN. As an implementation 
option, the DRNC may decide not to de-register from the MBMS bearer service immediately when these 
conditions are met, e.g. in order to avoid unnecessary signalling in the case where the RNC would again need the 
same MBMS bearer service shortly after. 

The SGSN removes the identifier of the RNC from the "list of downstream nodes" parameter of the affected 
MBMS Bearer Context and confirms the operation by sending an MBMS De-Registration Response message to 
the RNC. If an lu bearer plane had been established between the DRNC and the SGSN for this MBMS bearer 
service, the lu bearer plane is released. If the RNC is using IP multicast distribution it shall disable reception 
from the IP backbone of the particular MBMS bearer service according to RFC 3376 [17], RFC 3810 [18] and 
RFC 4604 [20]. 
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B. When the "list of downstream nodes" of a particular MBMS Bearer Context in the SGSN becomes empty and 
the SGSN has no MBMS UE Contexts linked to that MBMS Bearer Context, the SGSN sends an MBMS De- 
Registration Request (IP multicast address, APN) message to its upstream GGSN associated with the MBMS 
Bearer Context. 

The GGSN removes the identifier of the SGSN from the "list of downstream nodes" parameter of the affected 
MBMS Bearer Context and confirms the operation by sending an MBMS De-Registration Response message to 
the SGSN. If a bearer plane had been established between the SGSN and the GGSN for this MBMS bearer 
service, the bearer plane is released. 

C. When the "list of downstream nodes" of a particular MBMS Bearer Context in the GGSN becomes empty and 
the GGSN has no MBMS UE Contexts linked to that MBMS Bearer Context, the GGSN sends a De-Registration 
Request (IP multicast address, APN) message to the BM-SC. Proxy and Transport function If a bearer plane had 
been established over Gi for this MBMS bearer service, the bearer plane is released. 

The BM-SC removes the identifier of the GGSN from the "list of downstream nodes" parameter of the affected 
MBMS Bearer Context and confirms the operation by sending a De-Registration Response message to the 
GGSN. 

8.6.1 BM-SC initiated MBMS De-Registration Procedure 

This MBMS De-Registration Procedure is initiated by BM-SC when the specific MBMS bearer service is terminated. 
This procedure tears down the distribution tree for the delivery of session attributes and MBMS data. This procedure 
results in releasing of all MBMS Bearer Contexts and associated MBMS UE Contexts in the nodes along the 
distribution tree. 
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Figure 12: BM-SC initiated lUIBIUIS De-Registration Procedure 

1 . The BM-SC sends a De-Registration Request message to all GGSNs contained in the "list of downstream nodes" 
parameter of the corresponding MBMS Bearer Context to indicate the session is terminated and any related 
MBMS bearer resources shall be released. 

The GGSN returns a De-Registration Response message to the BM-SC. The BM-SC releases all MBMS UE 
Contexts and the corresponding MBMS Bearer context. 

2. The GGSN sends an MBMS De-Registration Request message to all SGSNs contained in the "Hst of 
downstream nodes" parameter, of the corresponding MBMS Bearer Context. The SGSN returns an MBMS De- 
registration Response message to the GGSN and releases all bearer resources if the state attribute of the MBMS 
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Bearer Context is 'Active'. The GGSN releases all MBMS UE Contexts and the affected MEMS Bearer Context. 
If a bearer plane had been established over Gi for this MBMS bearer service, the bearer plane is released. 

3. The SGSN sends an MBMS De-Registration Request message to all BSCs/RNCs connected with this SGSN. 
The BSC/RNC returns an MBMS De-Registration Response message to the SGSN, and releases all bearer 
resources if the state attribute of the MBMS Service Context is 'Active'. If the RNC is using IP multicast 
distribution it shall disable reception from the IP backbone of the particular MBMS bearer service according to 
RFC 3376 [17], RFC 3810 [18] and RFC 4604 [20]. The SGSN releases all MBMS UE Contexts and the 
affected MBMS Bearer Context. If a bearer plane had been established between the SGSN and the GGSN for 
this MBMS bearer service, the bearer plane is released. 

4. The BSC/RNC releases the affected radio resources, all MBMS UE Contexts and the MBMS Service Context. 
The detailed procedures are specified in TS 25.346 [10] and TS 43.246 [11]. RAN may notify the UEs that the 
MBMS Bearer service has being terminated, so that the UE can locally deactivate its MBMS UE context, 
detailed procedures are specified in TS 25.346 [10] and TS 43.246 [11]. 

8.7 MBMS Multicast Service Deactivation 

The multicast service deactivation is a signalling procedure between the UE and the network. The procedure removes 
the MBMS UE Context from the UE, RAN, SGSN and GGSN for a particular MBMS multicast service. The multicast 
service deactivation can be initiated by: 

- The UE; 

- The GGSN; 

- The BM-SC; or 

- The SGSN 

All these cases are contained in the procedure illustrated in figure 13. The UE initiated Multicast Service Deactivation 
starts with step 1), the BM-SC initiated Multicast Service Deactivation starts with step 3), the GGSN initiated Multicast 
Service Deactivation starts with step 4), the SGSN initiated Multicast Service Deactivation starts with step 5) or 9), and 
the MBMS UE de-linking is performed at step 7). 

At GPRS detach, all MBMS UE contexts of the UE are implicitly deactivated in the UE, SGSN and GGSN, i.e. the 
SGSN performs the deactivation procedure starting with step 7). 

If the PDP context linked to the MBMS UE context by the linked NS API is deactivated by the UE or SGSN or GGSN, 
then the SGSN shall perform the MBMS deactivation procedure starting with step 7). The UE will remove all MBMS 
UE Contexts locally after the Linked PDP Context was deactivated. 
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Figure 13: MBMS Multicast Service Deactivation 

1 . The UE sends an IGMP (IPv4) or MLD (IPv6) Leave message (here, the Leave message means Leave Group 
message in RFC 2236 for IGMP (IPv4) and Multicast Listener Done in RFC2710 for MLD (IPv6)) over the 
default PDP context to leave a particular multicast service identified by an IP multicast address. 

2. The GGSN sends a Leave Indication (IP multicast address, APN,IMSI) to the BM-SC Proxy and Transport 
function, which forwards it to the BM-SC Membership function, indicating that the UE is requesting to leave the 
multicast service identified by the IP multicast address. The exact nature of the signalling between GGSN and 
BM-SC is specified in TS 29.061 [4]. 

3. Upon reception of the Leave Indication, the BM-SC Membership function verifies that the IP multicast address 
corresponds to a valid MBMS bearer service and sends a UE Removal Request (IP multicast address, APN, 
IMSI) to the GGSN that originated the Leave Indication. The APN shall be the same that was provided during 
service activation (see "MBMS Multicast Service Activation"). The exact nature of the signalling between 
GGSN and BM-SC is specified in TS 29.061 [4]. The BM-SC Membership function may also initiate the 
deactivation of an MBMS UE Context for service-specific reasons (e.g. the service is terminated but the UE has 
not yet left the multicast group) by directly sending a UE Removal Request message to the GGSN. 

4. Upon reception of the UE Removal Request or for other reasons (e.g. Error cases), the GGSN sends an MBMS 
UE Context Deactivation Request (IP multicast address, APN, IMSI) to the SGSN. The IP multicast address, 
APN and IMSI together identify the MBMS UE Context to be deleted by the SGSN. The APN is the one 
received in step 3. The SGSN acknowledges reception of the MBMS UE Context Deactivation Request by 
sending an MBMS UE Context Deactivation Response to the GGSN. 
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5. Upon reception of the MBMS UE Context Deactivation Request or for other reasons (e.g. due to a change in the 
roaming restrictions for the user) the SGSN sends a Deactivate MBMS Context Request (TI) to the UE. The TI 
identifies the MBMS UE Context to be deleted by the UE. 

6. The UE deletes the MBMS UE Context and sends a Deactivate MBMS Context Accept (TI) to the SGSN. 

7. If the UE is PMM-CONNECTED and has been already linked towards the RAN, t he SGSN sends a MBMS UE 
De-Linking Request to the RNC (IP multicast address, APN, TMGI). RAN deletes the MBMS UE Context and 
sends a MBMS UE De-Linking Response (TMGI ) to the SGSN. 

8. If dedicated radio resources are currently assigned to the UE for the reception of the MBMS data, the RAN 
releases these radio resources. If shared radio resources are currently assigned for the distribution of the MBMS 
data, the RAN may decide to move the remaining UEs to dedicated resources. The detailed procedures and 
conditions are specified in TS 25.346 [10] and TS 43.246 [11]. 

9. Upon reception of the Deactivate MBMS Context Accept or for other reasons (e.g. due to expiry of the long 
timer that is started upon a periodic routeing area update not being received) the SGSN sends a Delete MBMS 
Context Request (MBMS_NSAPI) to the GGSN that holds the MBMS UE Context. This GGSN may be 
different from the GGSN that receives IGMP Leave request in step 1. 

10. The GGSN deletes the MBMS UE Context and sends a Deactivation Indication to the BM-SC to confirm the 
successful deactivation of the MBMS UE Context. The BM-SC, after receiving the Deactivation Indication, 
deletes the MBMS UE Context and sends a confirmation to the GGSN. The exact nature of the signalling 
between GGSN and BM-SC is specified in TS 29.061 [4]. 

1 1 . If the GGSN does not have any more users interested in this MBMS bearer service and the "list of downstream 
nodes" in the corresponding MBMS Bearer Context is empty, the GGSN sends a MBMS De-Registration 
Request to the BM-SC Proxy and Transport function. The BM-SC Proxy and Transport function responds with a 
MBMS De-Registration Response and removes the identifier of the GGSN from the "list of downstream nodes" 
parameter in its MBMS Bearer Context. See subclause "MBMS De-Registration Procedure". 

12. The GGSN confirms the deactivation of the MBMS UE Context to the SGSN by sending a Delete MBMS 
Context Response to the SGSN, which then deletes the MBMS UE Context. 

13. If the SGSN does not have any more users interested in this MBMS bearer service and the "list of downstream 
nodes" in the corresponding MBMS Bearer Context is empty, the SGSN sends an MBMS De-Registration 
Request to the GGSN. The GGSN responds with an MBMS De-Registration Response and removes the 
identifier of the SGSN from the "list of downstream nodes" parameter in its MBMS Bearer Context. See 
subclause "MBMS De-Registration Procedure". 

8.8 MBMS Session Update procedure 

8.8.1 General 

The MBMS Session Update procedure may be invoked by BM-SC or by SGSN. The BM-SC uses the procedure to 
update the service area for an ongoing MBMS Broadcast service session. The SGSN can also use the procedure to 
update the list of RAs where MBMS multicast users are located for an ongoing MBMS Multicast service session. 

8.8.2 SGSN initiated Session Update for MBMS Multicast service 

If the SGSN has provided a list of RAs in the MBMS Session Start Request message (even if the list was empty) and 
RAs are added or removed from the list, the SGSN shall use the MBMS Session Update procedure to inform the RNCs 
that the list has changed. The SGSN sends the Session Update message only to the RNCs that are affected by the list 
change. The procedure is used only during the MBMS Multicast service session and when SGSN has already sent a 
MBMS Session Start Request message to the RNC. 

If the SGSN has provided a list of RAs in the MBMS Session Start Request message (even if the list was empty) the 
SGSN shall send the Session Update to a RNC when: 

the first UE which have activated the service enters in a RA that is not in the list; 

the last UE which have activated the service leaves from a RA that was in the list. 
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Figure 13a. Session Update procedure 

1) The SGSN sends MBMS Session Update Request message to a RNC. 

2) The RNC acknowledges the MBMS Session Update Request with the MBMS Session Update Response 
message. 

8.8.3 BM-SC initiated Session Update for MBMS Broadcast service 

The BM-SC initiates the MBMS Session Update procedure when the service area for an ongoing MBMS Broadcast 
service session shall be modified. 

The attributes that can be modified by the Session Update Request are the MBMS Service Area, and the list of 
downstream nodes for GGSN (Broadcast only). A node receiving the Session Update Request determines how the 
attributes have changed by comparing the attributes in the message with corresponding attributes in its stored MBMS 
Bearer Context. 

A Session Update received in one node, results in a Session Update being sent to downstream nodes, to inform of the 
changed MBMS Service Area. If a Session Update with the List of SGSN parameter included is received in the GGSN, 
it does also result in a Session Start being sent to new downstream nodes, and in a Session Stop being sent to 
downstream nodes that have been removed from the list. 

The overall Session Update procedure is presented in figure 13b. 
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Figure 13b: Session Update procedure 

The BM-SC Session and Transmission function sends a Session Update Request (TMGI, Flow Identifier 
(Broadcast only), QoS, MBMS Service Area, Session identifier, estimated session duration, broadcast/multicast, 
list of downstream nodes for GGSN, time to MBMS data transfer) to the BM-SC Proxy and Transport function, 
which then forwards it to the GGSNs listed in the "list of downstream nodes" parameter of the corresponding 
MBMS Bearer Context. The TMGI and Session identifier identifies the ongoing session. The QoS, 
broadcast/multicast attributes and the 2G/3G indicator shall be identical as in the preceding Session Start 
message. The MBMS Service Area and the List of downstream nodes for GGSN define the new service area. 
The time to MBMS data transfer shall be set to and the estimated session duration shall be set to a value 
corresponding to the remaining part of the session. 

The GGSN stores the new session attributes and the list of downstream nodes in the MBMS Bearer Context and 
sends a Session Update Response message to the BM-SC Proxy and Transport function which forwards it to the 
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BM-SC Session and Transmission function. The BM-SC Proxy and Transport function copies the Session 
Update Request to the BM-SC Membership function for charging purposes. 

2. The GGSN compares the new Hst of downstream nodes with the Hst of downstream nodes it has stored in the 
MBMS Bearer Context. It sends an MBMS Session Start Request message to any added SGSN, an MBMS 
Session Stop Request to any removed SGSN, and an MBMS Session Update Request to the remaining SGSNs in 
the new Hst. 

3. The SGSN receiving an MBMS Session Update Request message, sends an MBMS Session Update Request 
message including the session attributes (TMGI, QoS, MBMS service Area, Session identifier, estimated session 
duration, broadcast/muhicast, time to MBMS data transfer, hst of RAs, etc.) to each BSC and/or each RNC that 
is connected to this SGSN. 

4. The BSCs/RNCs estabhsh or release the necessary radio resources for the transfer of MBMS data to the 
interested UEs. 

8.9 MBMS UE Context Synchronisation Procedure 

The Routing Area Update procedure transfers the MBMS UE Context status between UE and SGSN. This MBMS UE 
Context status identifies MBMS UE contexts, which are lost or deactivated only on one side. All MBMS UE Contexts, 
which are active on one side only shall be deactivated locally. If the UE wishes to re-activate the related MBMS bearer 
service, it shall join the MBMS bearer service again. See subclause 8.2 "MBMS Multicast Service Activation". 



UE 



SGSN 



1. Routeing Area Update Request 

N 



2. Routeing Area Update Accept 
< 



Figure 13b. MBMS UE Context Synchronisation procedure 

1) The UE sends Routeing Area Update Request to the SGSN. It includes the MBMS UE Context status, which 
indicates the UE's active MBMS UE Contexts. 

2) The SGSN sends Routeing Area Update Accept to the UE. It includes the MBMS UE Context status, which 
indicates the UE's MBMS UE Contexts that are stored in the SGSN. 

8.9a MBMS feature support indication 

An SGSN that supports MBMS shall indicate MBMS feature support to the UE during Routing Area Update procedure 
in the Routing Area Update Accept message and during GPRS attach procedure in the Attach Accept message. The UE 
then knows it can use already activated MBMS bearers, or activate new MBMS bearers according to subclause 8.2 
"MBMS Multicast Service Activation". 

An SGSN that does not support MBMS will not indicate MBMS feature support to the UE. This indicates to the UE that 
MBMS bearers are no longer supported, which may allow the UE to use point-to-point bearers for MBMS data transfer. 
In this case, the UE shall deactivate all active MBMS UE Contexts locally. 

8.10 Inter SGSN Routeing Area Update 

This procedure describes the handling of MBMS bearer services when an MBMS UE performs a Routeing Area Update 
and the serving SGSN changes. It is based on the Inter SGSN Routeing Area Update procedure specified in 
TS 23.060 [15]. The procedure is performed regardless whether MBMS sessions are ongoing or not. The handling of 
any PDP contexts established by the UE is not changed compared to the procedure without MBMS. The procedure 
described below does not show all details of the Routeing Area update procedure. Only for the MBMS specific 
additions the steps are described. 
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Figure 14: Inter SGSN Routeing Area Update 

2) An SGSN supporting MBMS indicates its MBMS support in the SGSN Context Request message. If the SGSN 
indicates that it supports MBMS, the old SGSN includes the transfer of the MBMS UE Context(s) in the SGSN 
Context Response message. 

7) For the MBMS UE context(s) received in step 2) the new SGSN sends Update MBMS UE Context Request 
(Serving network identity, MS Time Zone, CGI/SAI, RAT Type, Additional MBMS Trace Info) to the GGSNs 
concerned. The GGSNs update their MBMS UE Context fields and return Update MBMS UE Context Response. 

8) The GGSN sends Update MBMS UE Context Request (RAI) to the BM-SC. The inclusion of CGI/SAI shall be 
according rules detailed in subclause 15.1.1a in TS 23.060 [15]. The BM-SC updates its MBMS UE Context 
fields and return Update MBMS UE Context Response. 

9) If the GGSN receives new or updated Additional MBMS Trace Info from the new SGSN, the GGSN sends an 
Activate Trace (Additional MBMS Trace Info) message to the BM-SC. 
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14) In case the new SGSN indicated no MBMS support in step 2) the old SGSN deactivates all MBMS UE 
context(s) of the UE in SGSN, GGSN and BM-SC by initiating deactivation procedure(s) as described in 
subclause "8.7 MBMS Multicast Service Deactivation". 

15) If the old SGSN does not have any more MBMS UE Contexts for the MBMS bearer service(s) and the "list of 
downstream nodes" in the corresponding MBMS Bearer Context is empty, the SGSN initiates the MBMS De- 
Registration Procedure. See subclause "8.6 MBMS De-Registration Procedure". 

16) In case the new SGSN indicated MBMS support in step 2), the new SGSN verifies for each MBMS UE Context 
received whether it has a corresponding MBMS Bearer Context. For each MBMS Bearer Context that the SGSN 
does not already have, the SGSN creates an MBMS Bearer Context (in "Standby" state) and initiates the MBMS 
Registration Procedure towards the GGSN. See subclause "8.4 MBMS Registration Procedure". 

17) An SGSN without MBMS support does not indicate MBMS feature support in the Routing Area Update Accept 
message. On the other hand if the SGSN supports MBMS, the Routing Area Update Accept indicates to the UE 
that the network supports MBMS. 

8.10a Inter-system Intra-SGSN change 

For an MBMS UE transitioning between UTRAN and A/Gb mode GERAN, the procedures are the same as the lu mode 
to A/Gb mode Intra SGSN Change and A/Gb mode to lu mode Intra SGSN Change procedures specified in 
TS 23.060 [15]. 

Furthermore, the same considerations on Radio Access Technology changes apply as specified in the impacts of 
applying flow based charging specified in TS 23.060 [15], i.e. the SGSN shall send an Update MBMS UE Context 
Request to the GGSN. Subsequently the GGSN shall send an Update MBMS UE Context Request to the BM-SC as 
described in the Inter SGSN Routeing Area Update procedure in subclause 8.10. 

8.1 1 Inter SGSN Serving RNS Relocation Procedure 

This procedure is performed when the SGSN changes due to SRNS relocation. It bases on the SRNS Relocation 
procedure specified in TS 23.060 [15]. The procedure is performed regardless whether MBMS sessions are ongoing or 
not. The handling of any PDP contexts established by the UE is not changed compared to the procedure without 
MBMS. The procedure described below does not show all details of the SRNS relocation procedure. Only for the 
MBMS specific additions the steps are described. 
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Figure 15: SRNS Relocation Procedure 

3) The old SGSN transfers the MBMS UE Context(s). in the Forward Relocation Request message to the new 
SGSN 

5) An MBMS supporting SGSN indicates its MBMS support in the Forward Relocation Response message. 

14) In case the new SGSN supports MBMS it verifies for each MBMS UE Context received whether it has a 

corresponding MBMS Bearer Context. For each MBMS Bearer Context not yet existing in the SGSN the SGSN 
creates an MBMS Bearer Context (in "Standby" state) and initiates the MBMS Registration Procedure. See 
subclause "MBMS Registration Procedure". 
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16) In case the new SGSN indicated no MBMS support in step 3) the old SGSN deactivates all MBMS UE contexts 
of the UE in SGSN, GGSN and BMSC by initiating deactivation procedure(s) as described in clause "8.7 MBMS 
Multicast Service Deactivation". 

17) If the old SGSN does not have any more MBMS UE Contexts for this MBMS bearer service and the "Ust of 
downstream nodes" in the corresponding MBMS Bearer Context is empty, the SGSN initiates the MBMS De- 
Registration Procedure. See subclause "MBMS De -Registration Procedure". 

18) If the new SGSN supports the MBMS and for the MBMS UE context(s) received in step 5) the new SGSN sends 
Update MBMS UE Context Request (Serving network identity, MS Time Zone, CGI/SAI, RAT Type, 
Additional MBMS Trace Info) to the GGSNs concerned. The GGSNs update their MBMS UE Context fields and 
return Update MBMS UE Context Response. The GGSN sends updated Serving network identity to the BM-SC. 
The inclusion of CGI/SAI shall be according rules detailed in sub-clause 15.1.1a in TS 23.060 [15]. 

19)If the GGSN receives new or updated Additional MBMS Trace Info from the new SGSN, the GGSN sends an 
Activate Trace (Additional MBMS Trace Info) message to the BM-SC. 

20) An SGSN without MBMS support does not indicate MBMS feature support in the Routing Area Update Accept 
message. On the other hand if the SGSN supports MBMS, the Routing Area Update Accept indicates to the UE 
that the network supports MBMS. 

8.12 MBMS Broadcast Service Activation 

MBMS Broadcast service activation is the procedure by which a UE locally activates a broadcast MBMS bearer 
service: 

The MBMS broadcast service activation procedure does not register the user in the network. There is no MBMS 
bearer service specific signalling exchanged between the UE and the Network. 

The broadcast service activation procedure does not establish MBMS UE contexts in UE, SGSN and GGSN. 

8.13 MBMS Broadcast service de-activation 

The MBMS Broadcast service de-activation by the UE is local to the UE, i.e. without interaction with the Network. 

8.14 Void 

8.15 MBMS UE Linking/De-linking mechanism 

MBMS UE Linking is the process by which UE MBMS context(s) is (are) provided to an lu-mode RAN. 
MBMS UE linking procedure is performed when the UE is PMM-CONNECTED at least in the following cases. 

- When a UE which has a MBMS UE context is moved to the PMM CONNECTED state and a PS RAB is 
established. This may happen at any point in time e.g. before, during and between Sessions. 

- When a UE joins the MBMS bearer service and is in the PMM CONNECTED state due to an existing PS RAB. 
This may happen at any point in time e.g. before, during and between Sessions. 

When a UE is moved to the PMM CONNECTED state via the MBMS Service Request procedure. This may 
happen at any point in time during a MBMS session. 

The UE linking is performed to link a specific UE to an MBMS service. It provides the SRNC/Iu-mode BSC with a list 
of MBMS service identifiers (including TMGI) for MBMS bearer services activated by the UE. If no MBMS service 
context exists for this particular MBMS bearer service then the SRNC/Iu-mode BSC creates an MBMS service context 
after this procedure. 

NOTE: the MBMS Bearer Context is referred to as the MBMS Service Context in 3GPP RAN specifications 

MBMS UE De-Linking denotes the process where a MBMS UE context is removed from the RAN. 
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MBMS UE De-Linking procedure is performed if the UE is PMM-CONNECTED and has been akeady linked towards 
the RAN at least when it initiates MBMS Multicast Service Deactivation procedure. This may happen at any point in 
time during the whole MBMS service availability i.e. before, during and between MBMS sessions. 

The UE De-Linking is performed to unlink a specific UE from a MBMS service. The entry for this UE is removed from 
the concerned MBMS service context(s) in the SRNC. 

8.16 MBMS Service Request Procedure 

For MBMS, when UTRAN wants to count the number of users that are interested in a specific MBMS service which are 
present in a cell, it will request a percentage of the interested UEs to transit to PMM-CONNECTED state. The MBMS 
Service Request procedure is used by a UE in the PMM-IDLE state to move to the PMM-CONNECTED state. The 
MBMS Service Request procedure is also used by a UE in PMM IDLE or PMM-CONNECTED state to request to be 
maintained in PMM-CONNECTED state for the purpose of receiving data over an MBMS point-to-point radio bearer. 
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Figure 17: MBMS Service Request procedure 

1) An RRC connection is established if it doesn't already exist. 

2) The UE sends a Service Request message to the SGSN if MBMS PTP reception shall be used or if otherwise 
required to do so by the RAN when MBMS reception shall be started. The Service Type shall indicate MBMS 
multicast service reception or MBMS broadcast service reception. The SGSN shall not release the lu signalling 
connection until requested by the RAN. 

3) The SGSN may perform the security functions. 

4) The SGSN provides the RAN with the IMSI of the UE. 

5) The SGSN provides the RAN with the MBMS UE context(s) (IP multicast address/ APN, TMGI, 
MBMS_NSAPI) via MBMS UE Linking procedure, if the SGSN has active MBMS UE context(s) for the UE. 
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NOTE: Step 6 is independent of steps 4 to 5 and can occur before or simultaneously with any of these steps. 

6) The RNC establishes the necessary radio resources for the transfer of MBMS data to the interested UEs. 

7) When PTP transmission of a MBMS multicast or MBMS broadcast service is active for a UE then the RNC shall 
supervise the lu signalling connection. When the RAN determines that it does not need to keep the UE in RRC- 
CONNECTED state anymore, it shall trigger a normal lu release towards SGSN. 

8.1 7 Notification in case of parallel services 

8.17.1 Notification of incoming CS domain call during an ongoing MBMS 
session 

For the RRC connected mobiles in UTRAN, the RNS will have received the IMSI from the core network and hence is 
able to perform paging coordination. The UEs in RRC idle state in UTRAN need to perform paging coordination while 
receiving the MBMS session's user data. 

In GERAN, this is achieved by the UE monitoring its paging channels while receiving the MBMS session's user data. If 
the mobile responses to the CS paging in GERAN, then the ongoing MBMS service is likely to be interrupted in the 
UE. 

8.1 7.2 Notification of additional MBMS session during an ongoing MBMS 
session 

For the RRC connected mobiles in UTRAN, the SGSN has sent the list of MBMS bearer services that the user has 
activated to the UTRAN. The RNS needs to notify an RRC connected UE. 

For the UEs in RRC idle state, the UTRAN performs MBMS notification for the UE. 

In GERAN, this is achieved by the UE monitoring its paging channel(s) where notification is sent while receiving the 
MBMS session's user data. 

If the mobile accepts the new MBMS session in GERAN, then the ongoing MBMS service is likely to be interrupted in 
the UE. 

8.1 7.3 Notification of Mobile Terminating PS data during an ongoing MBMS 
session 

For the RRC connected mobiles in UTRAN, the SGSN request the establishment of a RAB which will be used to 
deliver the MT user data. 

For the UEs in RRC idle state, the UTRAN performs paging notification for the UE. 

In GERAN, this is achieved by the UE monitoring its paging channels while receiving the MBMS session's user data. 

If the mobile responses to the PS paging in GERAN, then the ongoing MBMS service is likely to be interrupted in the 
UE. 

8.1 7.4 Notification of MBMS session during an ongoing CS or PS domain 
"connection" 

When the UE establishes the UTRAN RRC connection for a CS service, the UE shall send a flag indicating that it has 
activated at least one MBMS bearer service. The RNC requests the SGSN to send the list of MBMS bearer services that 
the user has activated to enable the RNC to notify the UE when MBMS session starts. 

When a UE moves to PMM-connected state, the SGSN sends the list of MBMS bearer services that the user has 
activated to the RNC. The RNC notifies the UE when an MBMS session of the user's activated MBMS bearer services 
starts. 
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These procedures are not supported by GERAN in this version of the specification. 

9 Security 

Security of MBMS is found in TS 33.246 [5]. 

10 Charging requirement 
10.1 General 

The MBMS architecture shall support on-line and off-line charging. 

It shall be possible to collect charging information for the multicast mode. It shall also be possible to collect charging 
information for MBMS services in visited networks. 



MBMS shall collect charging information about the transmission of MBMS broadcast or multicast data that are 
provided by content or service providers (e.g. 3"* parties). This shall enable billing of broadcast and multicast content or 
service providers. 

To enable billing of broadcast and multicast content providers, data shall be collected at the BM-SC. 

NOTE: SGSN, GGSN and BM-SC generate charging data for the transmitted data, always under the assumption 
that the UEs are within the MBMS service area. If the MBMS service area is less than the PLMN, then 
there is the possibility that a UE will have moved outside the MBMS service area. Charging data will still 
be generated for that UE causing an inaccuracy in the data. This inaccuracy increases as the size of the 
MBMS service area is decreased. 



1 0.2 Bearer level charging for MBMS 



To provide bearer level charging for MBMS, mechanisms and functional elements described in TS 23.125 [12] are used 
for MBMS Bearer Contexts. 

Flow Based Charging (FBC) may be used to collect charging data records for MBMS Bearer Contexts e.g. for the 
purpose to charge the service provider, cf. TS 23.125 [12]. 

NOTE: Since multiple users share an MBMS bearer context FBC cannot be used for creating reports on a per user 
basis. 

1 0.3 Application level charging for MBMS 

In order to meet the MBMS charging requirements in TS 22.146 [2] and TS 22.246 [6], the following elements and 
functionalities are provided by the MBMS architecture: 

a) The MSISDN and IMSI are passed to the BM-SC. This provides the operator with the ability to associate GPRS 
location information (i.e. serving network idenity) with a user. 

b) In order to permit differential roaming tariffs, the serving network identity is provided to the BM-SC. 

c) Charging for MBMS services is based on application layer mechanisms, since it is only at the application layer 
that security is provided which can restrict content to authorised users or confirm delivery of content to users: 

The following general requirements apply to charging information generated by the BM-SC: 

Charging information generated for application layer charging events should include the above information 
provided by the GPRS network to facilitate differential roaming tariffs. 

Charging information should include an indication of the point at which the user had access to the content 
(e.g. if and when decryption keys for encrypted content are sent to the UE.). 
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1 0.4 Generation of charging records in the VPLIVIN 

In order to permit the settlement of inter-operator roaming charges , the SGSN needs to raise CDRs. The information 
that needs to be included on these CDRs is FFS. 



1 1 Roaming Support for IVIBIVIS user services 

11.1 Scenarios description 

There are three specific scenarios to provide MBMS user services to roaming users. 

One uses a GGSN in the HPLMN, the other two are enabled by use of the Mz interface and are further described below: 

A visited PLMN may offer to roaming users MBMS user services from their home PLMN. For this case, the 
PDF connection, which will be used for the JOIN step, may always be from the UE to the V-GGSN due to 
operator policy or routing optimization, then the authorization is done in the BM-SC in visited PLMN with the 
authorization information retrieved from the BM-SC in home PLMN. Then the MBMS user traffic is provided 
by the BM-SC in home PLMN and proxyed. An APN indicating a GGSN will be included in the authorisation 
information sent from home BM-SC to visited BM-SC. Whether GGSN of home or visited PLMN would be 
used is based on the operator policy, or agreement between PLMNs, for example, the visited BM-SC may 
modify the APN from the home BM-SC according to configuration of operator policy. 

Or, a visited PLMN may offer its own MBMS user services to roaming users when visited and home PLMN 
support the same classes of MBMS user services. For this case, the authorization is done in the BM-SC in visited 
PLMN with the authorization information retrieved from the BM-SC in home PLMN. Then the MBMS user 
traffic is provided by the BM-SC in visited PLMN. 

Editors' note: It is FFS how to deal with the services in the BM-SC in visited network which are not the same 
service class as supported by the BM-SC in home network. 

The usage of any of the scenarios and the offered MBMS user services are subject to the roaming agreement between 
visited and home PLMN operators. 

11.2 Scenario signalling flow 
11.2.1 APN selection 

When a UE is authorized through the BM-SC in the visited PLMN (by proxying the authorization signalling), an APN 
may be selected and decided by the BM-SC in the home PLMN or the BM-SC in the visit PLMN depending on the 
operator policy or agreement between PLMNs. See step 4 of the figure 18. 
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Figure 18: MBMS route optimization for l-IPLMN provided MBMS services 

Figure 18 is an extension of MBMS multicast service activation procedure described in clause 8.2, the only revise is 
that an authorization step (step 4) is added according to clause 11.1. 

4. The BM-SC in visited PLMN finds the BM-SC in home PLMN which will serve the UE based on the multicast 
IP address, and identity of the user, and sends the authorization request to it. The BM-SC in home PLMN can 
respond with an APN, which indicates a GGSN in home PLMN which will serve the UE for the specific MBMS 
service. The BM-SC in the visit network may modify the APN based on the operator policy or agreement 
between PLMNs. 
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Annex A (Informative): 
Void 
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Annex B (Informative): 
Void 



£75/ 



3GPP TS 23.246 version 8.4.0 Release 8 



55 



ETSI TS 123 246 V8.4.0 (2009-06) 



Annex C (Informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Cat 


Subject/Comment 


Old 


New 


2006-09 


SA#33 


SP-060650 


0173 


5 


c 


Allowing update of an MBMS service area 


6.10.0 


7.0.0 


2006-09 


SA#33 


SP-060573 


0175 


4 


B 


IVIBIVIS Roaming Support 


6.10.0 


7.0.0 


2006-12 


SA#34 


SP-060896 


0179 


3 


C 


Optimization on IVIBIVIS activation 


7.0.0 


7.1.0 


2006-12 


SA#34 


SP-060834 


0182 


1 


A 


GTP information in MBMS bearer context 


7.0.0 


7.1.0 


2006-12 


SA#34 


SP-060896 


0183 


2 


C 


Roaming solution based on routing optimization 


7.0.0 


7.1.0 


2006-12 


SA#34 


SP-060872 


0186 




A 


Initiation of Service Request to support MBMS broadcast 
services 


7.1.0 


7.1.1 


2007-03 


SA#35 


SP-070082 


0187 


3 


F 


APN selection for the Direct MBMS Multicast Activation 


7.1.1 


7.2.0 


2007-03 


SA#35 


SP-070082 


0188 


3 


F 


Support botfi IPv6 and IPv4 in MBMS 


7.1.1 


7.2.0 


2007-03 


SA#35 


SP-070082 


0189 


2 


F 


The Downstream Nodes of SGSN 


7.1.1 


7.2.0 


2007-06 


SA#36 


SP-070396 


0191 


2 


A 


PMM-Connected mode during MBMS enhanced broadcast 


7.2.0 


7.3.0 


2007-09 


SA#37 


SP-070533 


0194 




C 


Removal of Direction MBMS activation from rel 7 


7.3.0 


7.4.0 


2007-09 


SA#37 


SP-070544 


0195 




F 


Remove GGSN TEID-U from MBMS bearer context in SGSN 


7.4.0 


8.0.0 


2007-12 


SA#38 


SP-070812 


0198 


4 


B 


Including E-UTRAN and EPS to 23.246 


8.0.0 


8.1.0 


2008-06 


SA#40 


SP-080416 


0200 


2 


C 


Location dependent data flows for MBMS Broadcast 


8.1.0 


8.2.0 


2009-03 


SA#43 


SP-090121 


0207 




B 


Removal of eMBMS Architecture Principles from Rel-8 


8.2.0 


8.3.0 


2009-06 


SA#46 


SP-090410 


0202 


4 


B 


MBMS improvements for HSPA Evolution 


8.3.0 


8.4.0 


2009-06 


SA#46 


SP-090345 


0213 


1 


F 


Add clarification for MBMS session stop procedure and typo 
correction 


8.3.0 


8.4.0 



£75/ 



3GPP TS 23.246 version 8.4.0 Release 8 



56 



ETSI TS 123 246 V8.4.0 (2009-06) 



History 



Document history 


V8.2.0 


January 2009 


Publication 


V8.3.0 


March 2009 


Publication 


V8.4.0 


June 2009 


Publication 















£75/ 



